overriding getters and setters?

[Oleg Sivokon]

Once I encountered this problem myself, I was told that in this case I would
have to prefer the composition over inheritance :) And if you think about
for a while - it makes sense. DisplayObjects are big and robust classes
relatively to what you will add to them -> when you override something there
you may break some internal mechanism without even knowing that. Take for
example width property - it will also change when you modify scaleX,
transform.matrix, draw something into graphics (if this display object has
it), or, if it is a TextField with autoSize other then
TextFieldAutosize.NONE, then the width may change as you add / remove text
from it, change the scrollRect, change rotation (now, if you rotate by odd
number * 90 you swap height and width, besides, the width is always measured
along the parent X axis, so, every degree of rotation will produce a
different width value). This all means that in order to get a "widthChanged"
sort of event you must override a lot of properties, where some of them are
not really under your control because, for example Graphics is a final
class, and, I think that Transform is also a final class, besides, you can
also change size of the display object by passing it to a new instance of
Transform class and applying transformation there (AFAIK, this kind of
transformation bypasses width setter).
So, IMO, your best bet is to create a MyDisplayObject class with the only
property called width (or many similar properties, if you fill like it :))
and then apply the transformation to the display object contained within
this class.

Best.

Oleg

[Marc Weber]

Hi armencho,

That's what iain told me to do: adding a setSize(w,h) method.
That's what I've done.

does Flex (mxmlc) allow overriding it ?

In my simple case it doesn't matter. I can addd those 2 additional
lines.

But I'd like to learn more abou HaXe - mxmlc differences.

I don't have as3 completion on Linux yet so mxmlc is not an option for
now. But this may change in the future.

Marc Weber

[a***@public.gmane.org]

The thing is that haXe will refuse to accept an overriden property "width"
(and it IS overriden, because a superclass implements it) with anything more
than whatever access and getter/setter were specified for it, i.e. you will
only get away with identical but rather useless specification:

public var width: Float;

You will have to use something else to achieve what you want, I would
recommend a rather forward-compatible "set_width" setter:

public function set_width(width: Float)
{
this.width = width;
/// Invoke dependencies, or call "dispatchEvent(new Event("resize"));
for instance
return this.width;
}

Only flash.display.Stage objects dispatch a "resize" event, I am afraid.

I'd like to have a mask rounding corners.
s = new Shape()
[..]
s.drawRoundedRect(....)
[..]
movieclip.mask = s
Now I'd like that the movieclip resizez the mask whenever it get's
resied itself.
The MovieClip does not fire any RESIZE events itself, correct? (iain and
skatterbean told me on irc)
public class DisplayObject extends EventDispatcher implements
IBitmapDrawable
public function set width (value:Number) : void;
Is there a way to override it so that I can call
super.width = xxx;
resizeMyMask();
?
Is there another design pattern I can use?
Marc Weber
--
haXe - an open source web programming language
http://haxe.org

[Nicolas Cannasse]

Post by a***@public.gmane.org
The thing is that haXe will refuse to accept an overriden property
"width" (and it IS overriden, because a superclass implements it) with
anything more than whatever access and getter/setter were specified for
it, i.e. you will only get away with identical but rather useless

Yes, it is not possible right now to override native as3 getter/setter
methods. We need to find a way to support it, any suggestion ?

Nicolas

[a***@public.gmane.org]

Just an opinion, and also coming from someone who spends most of his time
today programming ECMAScript-262 compatible languages (JavaScript,
ActionScript 1 and 3) and runtimes (AVM2, Tamarin, etc)

In ActionScript 3 it is NOT possible to redefine instance variable
definitions in subclasses, when these are defined originally in a
superclass. HOWEVER, it IS possible to redefine their getters/setters. From
an Adobe document titled "Programming Adobe ActionScript 3 for Adobe Flash":

"Overriding variables not permitted
Properties that are declared with the var or const keywords are inherited
but cannot be overridden. To override a
property means to redefine the property in a subclass. The only type of
property that can be overridden are methods—
that is, properties declared with the function keyword. Although you cannot
override an instance variable, you can
achieve similar functionality by creating getter and setter methods for the
instance variable and overriding the
methods. For more information, see “Overriding methods” on page 111."

An example is given as well:

package
{
import flash.display.MovieClip;
public class OverrideExample extends MovieClip
{
public function OverrideExample()
{
trace(currentLabel)
}
override public function get currentLabel():String
{
var str:String = "Override: ";
str += super.currentLabel;
return str;
}
}
}

The important thing in the above is the fact that "currentLabel" is a
property of a MovieClip, however its behavior is changed by subclass
redefining its "getter" method.

Is doing something similiar feasable with haXe, without compromising
similiar functionality for the other platforms it targets?

On Wed, Mar 10, 2010 at 14:26, Nicolas Cannasse

Post by a***@public.gmane.org
The thing is that haXe will refuse to accept an overriden property "width"

Post by a***@public.gmane.org
(and it IS overriden, because a superclass implements it) with anything more
than whatever access and getter/setter were specified for it, i.e. you will

Yes, it is not possible right now to override native as3 getter/setter
methods. We need to find a way to support it, any suggestion ?
Nicolas
--
haXe - an open source web programming language
http://haxe.org

[Hugh Sanderson]

Hi,
Not 100% sure I'm on the right path, but maybe some name convention magic:

function __get_width() : Float

gets compiled as:

function get width():Float

Or maybe via some 'extern' syntax:

var width(extern my_set_width,extern my_get_width):Float
function my_get_width() { return 123; }

ALSO generates:
function get width():Float { return my_get_width(); }

OR maybe a syntax:

var width(extern,extern):Float

*requires* the function:
function __get_width() : Float,

which gets compiled to native "get width"


I think things to think about:
1. overriding
2. writing as3 libraries in haxe (ie, new properties)
3. dynamic properties in as3

Hugh

Post by Nicolas Cannasse

Post by a***@public.gmane.org
The thing is that haXe will refuse to accept an overriden property
"width" (and it IS overriden, because a superclass implements it) with
anything more than whatever access and getter/setter were specified for
it, i.e. you will only get away with identical but rather useless

Yes, it is not possible right now to override native as3 getter/setter
methods. We need to find a way to support it, any suggestion ?
Nicolas

[Franco Ponticelli]

I'd suggest adding a new keyword for property modifiers that prepends the
function name.
So, if I do

var width(getter getWidth, setter setWidth) : Int;

should be quite obvious. In case of platforms that fully support accessors
the getWidth function will not be generated at all, for other platforms it
will work as it does now.

Franco.

Post by Hugh Sanderson
Hi,
function __get_width() : Float
function get width():Float
var width(extern my_set_width,extern my_get_width):Float
function my_get_width() { return 123; }
function get width():Float { return my_get_width(); }
var width(extern,extern):Float
function __get_width() : Float,
which gets compiled to native "get width"
1. overriding
2. writing as3 libraries in haxe (ie, new properties)
3. dynamic properties in as3
Hugh

Post by Nicolas Cannasse

Post by a***@public.gmane.org
The thing is that haXe will refuse to accept an overriden property
"width" (and it IS overriden, because a superclass implements it) with
anything more than whatever access and getter/setter were specified for it,

Yes, it is not possible right now to override native as3 getter/setter
methods. We need to find a way to support it, any suggestion ?
Nicolas

--
haXe - an open source web programming language
http://haxe.org

[Nicolas Cannasse]

Post by Franco Ponticelli
I'd suggest adding a new keyword for property modifiers that prepends
the function name.
So, if I do
var width(getter getWidth, setter setWidth) : Int;

I hate new keywords :)

What about using metadata for it ?

@get @set var width : Int;

@get(width) override function getWidth() : Int {
}

Nicolas

[Heinz Hölzer]

I think it's important to have a syntax that works for flash, but is
compatible to neash.
Maybe it's the best to mark a property by metadata, but leave the code
as usual.

maybe

@flashGetterSetterOverride
var width(getWidth, setWidth);

private function getWidth() : Int {
}
private function setWidth(v:Int) : Int {
}

so the compiler knows that this property must be treated as a special
flash property.

Post by Nicolas Cannasse

Post by Franco Ponticelli
I'd suggest adding a new keyword for property modifiers that prepends
the function name.
So, if I do
var width(getter getWidth, setter setWidth) : Int;

I hate new keywords :)
What about using metadata for it ?
@get @set var width : Int;
@get(width) override function getWidth() : Int {
}
Nicolas

[Franco Ponticelli]

what about this?

var width(@getWidth, @setWidth);

private function getWidth() : Int {
}
private function setWidth(v:Int) : Int {
}

[a***@public.gmane.org]

I have always been stupid, so please don't be alarmed, but
I fail to follow the debate, specifically how is what you are discussing
different from the following already existing syntax:

var width(get_width, set_width): Float; // 'width' is a Float btw ;-)

Are you inventing some form of native getter-setters and trying to find a
good looking syntax for it?

Will it not be confusing to have the new syntax with the one above?

I am sorry I am so slow :|
Have any of you taken a look at the Adobe paper I quoted from? Is it
relevant?

On Wed, Mar 10, 2010 at 18:24, Franco Ponticelli <

Post by Franco Ponticelli
what about this?
private function getWidth() : Int {
}
private function setWidth(v:Int) : Int {
}
--
haXe - an open source web programming language
http://haxe.org

[Mark de Bruijn | Dykam]

That would be good too. It doesn't really matter...
--
Mark

Post by Franco Ponticelli
I'd suggest adding a new keyword for property modifiers that prepends the

Post by Franco Ponticelli
function name.
So, if I do
var width(getter getWidth, setter setWidth) : Int;

I hate new keywords :)
What about using metadata for it ?
@get @set var width : Int;
@get(width) override function getWidth() : Int {
}
Nicolas
--
haXe - an open source web programming language
http://haxe.org

[Marc Weber]

Use case:

I'd like to have a mask rounding corners.
This can be done easyl:

s = new Shape()
[..]
s.drawRoundedRect(....)
[..]
movieclip.mask = s

Now I'd like that the movieclip resizez the mask whenever it get's
resied itself.

The MovieClip does not fire any RESIZE events itself, correct? (iain and
skatterbean told me on irc)

Now opensource Flash sources tell me there is a setter method:


public class DisplayObject extends EventDispatcher implements IBitmapDrawable

public function set width (value:Number) : void;


Is there a way to override it so that I can call

super.width = xxx;
resizeMyMask();

?

Is there another design pattern I can use?

Marc Weber

[a***@public.gmane.org]

I agree with Oleg - composite a DisplayObject, rather than inheriting it.
You get a bonus then as well - to be able to have the "width" getter/setter
for your compositing object, and have it propagate the necessary
dependencies down to whatever needs to be updated. Another bonus is
decoupling your code from platform - you will be able to port it easier to
other platforms than Flash, because the native platform class objects are
more isolated from your own application logic.

Post by Oleg Sivokon
Once I encountered this problem myself, I was told that in this case I
would have to prefer the composition over inheritance :) And if you think
about for a while - it makes sense. DisplayObjects are big and robust
classes relatively to what you will add to them -> when you override
something there you may break some internal mechanism without even knowing
that. Take for example width property - it will also change when you modify
scaleX, transform.matrix, draw something into graphics (if this display
object has it), or, if it is a TextField with autoSize other then
TextFieldAutosize.NONE, then the width may change as you add / remove text
from it, change the scrollRect, change rotation (now, if you rotate by odd
number * 90 you swap height and width, besides, the width is always measured
along the parent X axis, so, every degree of rotation will produce a
different width value). This all means that in order to get a "widthChanged"
sort of event you must override a lot of properties, where some of them are
not really under your control because, for example Graphics is a final
class, and, I think that Transform is also a final class, besides, you can
also change size of the display object by passing it to a new instance of
Transform class and applying transformation there (AFAIK, this kind of
transformation bypasses width setter).
So, IMO, your best bet is to create a MyDisplayObject class with the only
property called width (or many similar properties, if you fill like it :))
and then apply the transformation to the display object contained within
this class.
Best.
Oleg
--
haXe - an open source web programming language
http://haxe.org

[Oleg Sivokon]

If it was possible to override flash.* classes' properties, that would help.
Not in this particular case with width, because doing so in AS3 would have
the same not so very good consequences, but, in general, sometimes you
almost have to do that because the native code has it wrong, as well as a
bunch of other reasons. One more reason to mention - meta-programming, like
MXML, where everything is based on properties (not methods).

I think new keyword implies that you may change the signature (and I'm not
sure it is a good thing to do)... But other then that, the idea sounds good.
On the other hand it seems a little bit overkill to add a new keyword just
to solve this particular problem. Maybe, if I can suggest, AS3 has "native"
access modifier, it is restricted for AS3 to access fields in that namespace
(but in early versions it was possible). So, maybe use something like:

override native width(default,default):Float;

which would signal to perform some platform specific operation rather than
what HaXe normally does in such case. This may probably solve similar issues
on other platforms, where for some reason HaXe own syntax won't cut it. Or,
maybe just extend the use of "untyped" to do this kind of things as well?

Best.

Oleg

[Tony Polinelli]

I am with armencho (in not fully understanding the issue - so please
bear with me)

I know its been mentioned before - but never with much of a reply as
to whether its a good idea or not - but would having standardized
naming help?

http://markmail.org/message/okl7gjnhtvkhcycb#query:related%3Aokl7gjnhtvkhcycb+page:1+mid:tvbzsg47xcrm5lem+state:results

If haxe used similar getter/setter syntax to as3 in the 'public
function get x' (being compiled to __get_x() - or similar) then this
could (via magic) override the existing as3 native getter (as Hugh
commented?) - if you define 'override' to the defenition. As per my
earlier disclaimer - Maybe i dont understand the workings of AVM2 ;(
This would obviously be a fair change to the compiler - maybe haxe 3 ?

It would also allow the runtime getters and setters to work in haxe
via Relect checking for the defined __get_ or __set_ methods before
accessing a property.

Post by Oleg Sivokon
If it was possible to override flash.* classes' properties, that would help.
Not in this particular case with width, because doing so in AS3 would have
the same not so very good consequences, but, in general, sometimes you
almost have to do that because the native code has it wrong, as well as a
bunch of other reasons. One more reason to mention - meta-programming, like
MXML, where everything is based on properties (not methods).
I think new keyword implies that you may change the signature (and I'm not
sure it is a good thing to do)... But other then that, the idea sounds good.
On the other hand it seems a little bit overkill to add a new keyword just
to solve this particular problem. Maybe, if I can suggest, AS3 has "native"
access modifier, it is restricted for AS3 to access fields in that namespace
override native width(default,default):Float;
which would signal to perform some platform specific operation rather than
what HaXe normally does in such case. This may probably solve similar issues
on other platforms, where for some reason HaXe own syntax won't cut it. Or,
maybe just extend the use of "untyped" to do this kind of things as well?
Best.
Oleg
--
haXe - an open source web programming language
http://haxe.org

[a***@public.gmane.org]

What I don't understand is that haXe already has a very usable syntax:

var prop(getter, setter): Type;

while now, it is discussed to use some weirdness on top of it, like:

var prop(__get, __set): Type;

or even

var prop(getProp, setProp): Type

which makes me wonder, why it is needed at all?
I am guessing the new syntax is for native getters and setters for the Flash
platform? I.e. those that can be overriden?
In any case why force people to use the "lowerCamelCase"?

Post by Tony Polinelli
I am with armencho (in not fully understanding the issue - so please
bear with me)
I know its been mentioned before - but never with much of a reply as
to whether its a good idea or not - but would having standardized
naming help?
http://markmail.org/message/okl7gjnhtvkhcycb#query:related%3Aokl7gjnhtvkhcycb+page:1+mid:tvbzsg47xcrm5lem+state:results
If haxe used similar getter/setter syntax to as3 in the 'public
function get x' (being compiled to __get_x() - or similar) then this
could (via magic) override the existing as3 native getter (as Hugh
commented?) - if you define 'override' to the defenition. As per my
earlier disclaimer - Maybe i dont understand the workings of AVM2 ;(
This would obviously be a fair change to the compiler - maybe haxe 3 ?
It would also allow the runtime getters and setters to work in haxe
via Relect checking for the defined __get_ or __set_ methods before
accessing a property.

Post by Oleg Sivokon
If it was possible to override flash.* classes' properties, that would

help.

Post by Oleg Sivokon
Not in this particular case with width, because doing so in AS3 would

have

Post by Oleg Sivokon
the same not so very good consequences, but, in general, sometimes you
almost have to do that because the native code has it wrong, as well as a
bunch of other reasons. One more reason to mention - meta-programming,

like

Post by Oleg Sivokon
MXML, where everything is based on properties (not methods).
I think new keyword implies that you may change the signature (and I'm

not

Post by Oleg Sivokon
sure it is a good thing to do)... But other then that, the idea sounds

good.

Post by Oleg Sivokon
On the other hand it seems a little bit overkill to add a new keyword

just

Post by Oleg Sivokon
to solve this particular problem. Maybe, if I can suggest, AS3 has

"native"

Post by Oleg Sivokon
access modifier, it is restricted for AS3 to access fields in that

namespace

Post by Oleg Sivokon
override native width(default,default):Float;
which would signal to perform some platform specific operation rather

than

Post by Oleg Sivokon
what HaXe normally does in such case. This may probably solve similar

issues

Post by Oleg Sivokon
on other platforms, where for some reason HaXe own syntax won't cut it.

Or,

Post by Oleg Sivokon
maybe just extend the use of "untyped" to do this kind of things as well?
Best.
Oleg
--
haXe - an open source web programming language
http://haxe.org

--
Tony Polinelli
http://touchmypixel.com
--
haXe - an open source web programming language
http://haxe.org

[Tony Polinelli]

okay i'm going to think aloud (hope i'm right ;P)-

As i understand it the problem is that in haxe x(getX,setX) relies on
a seperate method getX, for example, to 'get' the x value - whereas in
avm2 the x propery can 'be' a getter - so when x (as a property) is
refered to a x (as a method) is called.

This is why in haxe you can have setX receive a value and set it to
'x' - without getting in a loop - since 'x' actually exists as a
simple property at runtime (also the compiler ignores the setter in
the setter block).

So, at runtime when you access 'x' you are accessing the property, not
the getter/setter, so the compiler bakes in the getters and setters at
compiletime - ie puts in function calls instead of accessing 'x'.

but

as Hugh said, var x(__get_x, __set_x) could refer to the avm2 'native'
getter/setter functions if they already exist- as in the case of
extending a DisplayObject. It might need to ignore redefining x as a
property here too tho. it is a bit messy however. - really this
shouldn't be allowed since you are overriding a property.

so
override function __get_x() - makes sense. (as a magic)

having 'override function get x' in haxe could also refer to a native
OR create getX method (maybe)

well thats how i (think) things happen

Post by a***@public.gmane.org
var prop(getter, setter): Type;
var prop(__get, __set): Type;
or even
var prop(getProp, setProp): Type
which makes me wonder, why it is needed at all?
I am guessing the new syntax is for native getters and setters for the Flash
platform? I.e. those that can be overriden?
In any case why force people to use the "lowerCamelCase"?

Post by Tony Polinelli
I am with armencho (in not fully understanding the issue - so please
bear with me)
I know its been mentioned before - but never with much of a reply as
to whether its a good idea or not - but would having standardized
naming help?
http://markmail.org/message/okl7gjnhtvkhcycb#query:related%3Aokl7gjnhtvkhcycb+page:1+mid:tvbzsg47xcrm5lem+state:results
If haxe used similar getter/setter syntax to as3  in the 'public
function get x' (being compiled to __get_x() - or similar) then this
could (via magic) override the existing as3 native getter (as Hugh
commented?) - if you define 'override' to the defenition. As per my
earlier disclaimer - Maybe i dont understand the workings of AVM2 ;(
This would obviously be a fair change to the compiler - maybe haxe 3 ?
It would also allow the runtime getters and setters to work in haxe
via Relect checking for the defined __get_ or __set_ methods before
accessing a property.

Post by Oleg Sivokon
If it was possible to override flash.* classes' properties, that would help.
Not in this particular case with width, because doing so in AS3 would have
the same not so very good consequences, but, in general, sometimes you
almost have to do that because the native code has it wrong, as well as a
bunch of other reasons. One more reason to mention - meta-programming, like
MXML, where everything is based on properties (not methods).
I think new keyword implies that you may change the signature (and I'm not
sure it is a good thing to do)... But other then that, the idea sounds good.
On the other hand it seems a little bit overkill to add a new keyword just
to solve this particular problem. Maybe, if I can suggest, AS3 has "native"
access modifier, it is restricted for AS3 to access fields in that namespace
override native width(default,default):Float;
which would signal to perform some platform specific operation rather than
what HaXe normally does in such case. This may probably solve similar issues
on other platforms, where for some reason HaXe own syntax won't cut it. Or,
maybe just extend the use of "untyped" to do this kind of things as well?
Best.
Oleg
--
haXe - an open source web programming language
http://haxe.org

--
Tony Polinelli
http://touchmypixel.com
--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org

[Cauê Waneck]

Hey guys, maybe the syntax shouldn't be changed at all.

The main problem that causes incompatibilities between haXe and as3 is that,
as Tony said, the actual variable exists as a separate entity.

so for example,
var x(getX, setX):Float

the x variable will be accessible from inside the getX and setX functions.

What if we actually change this simple variable - in the case, the variable
'x', to something like '$x'? All variable-only access will be replaced by $
+ variable, while x will become:

public function get x():void
{
return getX();
}

public function set x(val:Number):void
{
setX(val);
}

HaXe will handle the getters and setters the same way it does now, to
generate optimized code (e.g. inline getters/setters), while runtime access
will be guaranteed.

For overriding the actual native api's getters and setters, maybe it could
be done with a syntax like that:

//on DisplayObject.hx

var x(_, _):Float;

so it will mark on the extern definition that the native getters and setters
exist, and can be overriden.

Post by Tony Polinelli
okay i'm going to think aloud (hope i'm right ;P)-
As i understand it the problem is that in haxe x(getX,setX) relies on
a seperate method getX, for example, to 'get' the x value - whereas in
avm2 the x propery can 'be' a getter - so when x (as a property) is
refered to a x (as a method) is called.
This is why in haxe you can have setX receive a value and set it to
'x' - without getting in a loop - since 'x' actually exists as a
simple property at runtime (also the compiler ignores the setter in
the setter block).
So, at runtime when you access 'x' you are accessing the property, not
the getter/setter, so the compiler bakes in the getters and setters at
compiletime - ie puts in function calls instead of accessing 'x'.
but
as Hugh said, var x(__get_x, __set_x) could refer to the avm2 'native'
getter/setter functions if they already exist- as in the case of
extending a DisplayObject. It might need to ignore redefining x as a
property here too tho. it is a bit messy however. - really this
shouldn't be allowed since you are overriding a property.
so
override function __get_x() - makes sense. (as a magic)
having 'override function get x' in haxe could also refer to a native
OR create getX method (maybe)
well thats how i (think) things happen

Post by a***@public.gmane.org
var prop(getter, setter): Type;
var prop(__get, __set): Type;
or even
var prop(getProp, setProp): Type
which makes me wonder, why it is needed at all?
I am guessing the new syntax is for native getters and setters for the

Flash

Post by a***@public.gmane.org
platform? I.e. those that can be overriden?
In any case why force people to use the "lowerCamelCase"?

Post by Tony Polinelli
I am with armencho (in not fully understanding the issue - so please
bear with me)
I know its been mentioned before - but never with much of a reply as
to whether its a good idea or not - but would having standardized
naming help?

http://markmail.org/message/okl7gjnhtvkhcycb#query:related%3Aokl7gjnhtvkhcycb+page:1+mid:tvbzsg47xcrm5lem+state:results

Post by a***@public.gmane.org

Post by Tony Polinelli
If haxe used similar getter/setter syntax to as3 in the 'public
function get x' (being compiled to __get_x() - or similar) then this
could (via magic) override the existing as3 native getter (as Hugh
commented?) - if you define 'override' to the defenition. As per my
earlier disclaimer - Maybe i dont understand the workings of AVM2 ;(
This would obviously be a fair change to the compiler - maybe haxe 3 ?
It would also allow the runtime getters and setters to work in haxe
via Relect checking for the defined __get_ or __set_ methods before
accessing a property.

Post by Oleg Sivokon
If it was possible to override flash.* classes' properties, that would help.
Not in this particular case with width, because doing so in AS3 would have
the same not so very good consequences, but, in general, sometimes you
almost have to do that because the native code has it wrong, as well

as

Post by a***@public.gmane.org

Post by Tony Polinelli

Post by Oleg Sivokon
a
bunch of other reasons. One more reason to mention - meta-programming, like
MXML, where everything is based on properties (not methods).
I think new keyword implies that you may change the signature (and I'm not
sure it is a good thing to do)... But other then that, the idea sounds good.
On the other hand it seems a little bit overkill to add a new keyword just
to solve this particular problem. Maybe, if I can suggest, AS3 has "native"
access modifier, it is restricted for AS3 to access fields in that namespace
override native width(default,default):Float;
which would signal to perform some platform specific operation rather than
what HaXe normally does in such case. This may probably solve similar issues
on other platforms, where for some reason HaXe own syntax won't cut

it.

Post by a***@public.gmane.org

Post by Tony Polinelli

Post by Oleg Sivokon
Or,
maybe just extend the use of "untyped" to do this kind of things as well?
Best.
Oleg
--
haXe - an open source web programming language
http://haxe.org

--
Tony Polinelli
http://touchmypixel.com
--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org

--
Tony Polinelli
http://touchmypixel.com
--
haXe - an open source web programming language
http://haxe.org

[Marc Weber]

Hi Oleg,

Post by Oleg Sivokon
have to prefer the composition over inheritance :) And if you think about

Well in days when I wrote Delphi there was a parent property:

c = new TextField
c.parent = form;
c.visible = true;

(or something like this)

setting the parent property attaches and detaches to/from a parent.

Maybe I'm looking for something like this as well here.

class MyContainer {

public var parent(getParent, setParent) : MyContainer;

// setParent calls removeChild and addChild

public var width(getWidth, setWidth); // ..

}

Then I can model my resezing stuff using objects. You're right: I can port it
easily. (I don't want in this use case).


The question I have now is: Has someone already done this kind of wrapping or
should I start reinventing the wheel?

The HaXe book talks about Stacklayouts and PanelLayouts etc.
Writing layouts without handling resizing doesn't make much sense.
So maybe someone already has done all the work?

I know how to get my job done - But i don't like writing so much additional code.
It's a nice practise though.

Marc Weber