Hard to override classes - Making privates protected?

[IonSwitz]

Just a small question here:

Is there a reason for most of the classes to have "private" rather than "protected" members? Such as the Stroke class, for example? Or the Graphics class?

The code base is magnificent, but with the private member variables, it's kind of hard to extend without basically copying the existing classes, renaming them and making the member variables "protected".

I wouldn't mind doing the work to change them to "protected", but I won't do it if there's a decision or a reason not to open them up for extension...

Let me know what you think, @robsilv and you others.

[robsilv]

Hi @IonSwitz,

No reason (AFAIK), other than habit. Glad you approve of the code! I'm sure @jonathanrpace will be happy to hear that. :-) Please feel free to change any private variables to protected at your discretion.

Cheers Rob

[IonSwitz]

@robsilv I am spreading my comments high and low here. I am sorry about that. I have now committed/synched up my latest changes and the clean up of my code. Some changes have been made to a few of the base classes, but it is only made in order to be able to override them.

I haven't done a full sweep of private-to-protected yet, mainly Graphics, Stroke and Fill has been changed. I have also broken out the StrokeVertex to a public class, since that was needed for the post processing. If this is too much a breakage of the "real" API, then I'm not sure how to solve the post processing nicely.

I have some test/sample code to show off this stuff, but I'm not quite sure where to stick it.

In short, it looks like this:

var shape:ShapeEx = new ShapeEx(); shape.blendMode = BlendMode.ADD; addChild(shape);

shape.graphics.lineMaterial( 1, lavaMaterial); shape.graphics.moveTo( 900, 550 );

var firstPoint:int = shape.graphics.currentLineIndex; // Grab first index point before we add anything var controlPoints:Array = [new Point(900, 550), new Point(700, 130), new Point(150, 180), new Point(200, 650), new Point(500, 650), new Point(700, 650)]; shape.graphics.naturalCubicSplineTo(controlPoints, false, 100); var midPoint:int = shape.graphics.currentLineIndex/2; // Midpoint can be had by dividing length in half. var endPoint:int = shape.graphics.currentLineIndex-1; // End point is one off the current index.

var colorData:GraphicsExColorData = new GraphicsExColorData(0xFF0000, 0xFFFFFF, 0.0, 1.0); var thicknessData:GraphicsExThicknessData = new GraphicsExThicknessData(1, 30); // run postProcess from start to midpoint, go from red to white, alpha 0 to 1, thickness 1 to 30 pixels shape.graphics.postProcess(firstPoint, midPoint, thicknessData, colorData );

colorData = new GraphicsExColorData(0xDDDDFF, 0xDDFFFF, 1.0, 0.0, null, null); thicknessData = new GraphicsExThicknessData(30, 1); // run postProcess from midpoint to end, go from 0xDDDDFF to 0xDDFFFF, alpha 1 to 0, thickness 30 to 1 pixels shape.graphics.postProcess(midPoint, endPoint, thicknessData, colorData );

[IonSwitz]

Just as GitHub experienced a 10 minute outage, I committed an Example ( 08_GraphicsEx_Spline_Example ) showing the use of the spline code, the postProcessing for color, alpha and thickness (no support for the call back functions yet) and a pretty fun combination of Vertex and Fragment shaders to play with, using the Glow texture of the Lava example.

I am using FlashDevelop, so the project file is for that IDE, and not FDT or whatever the other Examples use. I am unable to create the .project file for this example.

[robsilv]

Cool! I look forward to having a play with it tomorrow. :-) Regarding the "real API", the way I see it, there's API 1 and API2.

API 1 is the Flash Graphics API clone. While I don't expect we'll be able to make this blazing fast (from previous conversations with @jonathanrpace), I think it's important to keep this API as similar as possible to the Flash Graphics API to allow Flash devs to get a foothold.

API 2, as demonstrated here and here can be however we like, and will probably be the natural choice for more advanced users who need more control and better performance. So as long as API 1 stays fairly true to Flash Graphics, then please don't feel restricted in augmenting API 2 with whatever you need to make it awesome.

Hope that makes sense!