Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Jordo Odroj
I've been running into a problem lately. The problem is that sometimes
I forget to initialize my member variables in the constructor. This
has caused me quite a lot of pain trying to come up with ways that
force members to be defined at construction time. In Java, there is a
final keyword, which will require that a final member has been
assigned at construction time.
This is very important for the following reason.

This eliminates the possibility, or at least the window of time for
which your object may be in an invalid state.
The fact that objects can be null, makes this problem more serious. Of
course, allowing nulls to exist in the language and the lack of
'final' go hand in hand.
Does putting a final concept in the language sound like something that
would belong in Haxe?

Does anyone have any workarounds to ensure that my data always is in a
state of integrity?

Jordo

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Baluta Cristian
One solution would be to not forget initing them. You can do that with a macro function called _init_ i think, which is called before everything else automatically. So the problem resumes at not forgetting to use this function.


On Tue, Mar 22, 2011 at 9:36 AM, Jordo Odroj <[hidden email]> wrote:
I've been running into a problem lately. The problem is that sometimes
I forget to initialize my member variables in the constructor. This
has caused me quite a lot of pain trying to come up with ways that
force members to be defined at construction time. In Java, there is a
final keyword, which will require that a final member has been
assigned at construction time.
This is very important for the following reason.

This eliminates the possibility, or at least the window of time for
which your object may be in an invalid state.
The fact that objects can be null, makes this problem more serious. Of
course, allowing nulls to exist in the language and the lack of
'final' go hand in hand.
Does putting a final concept in the language sound like something that
would belong in Haxe?

Does anyone have any workarounds to ensure that my data always is in a
state of integrity?

Jordo

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



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Gamehaxe
Hi,
Yes, I would really like to see the ability to init non-static member  
variables at
declaration time. It make so much sense.

Hugh

> One solution would be to not forget initing them. You can do that with a
> macro function called _init_ i think, which is called before everything  
> else
> automatically. So the problem resumes at not forgetting to use this
> function.
>
>
> On Tue, Mar 22, 2011 at 9:36 AM, Jordo Odroj <[hidden email]> wrote:
>
>> I've been running into a problem lately. The problem is that sometimes
>> I forget to initialize my member variables in the constructor. This
>> has caused me quite a lot of pain trying to come up with ways that
>> force members to be defined at construction time. In Java, there is a
>> final keyword, which will require that a final member has been
>> assigned at construction time.
>> This is very important for the following reason.
>>
>> This eliminates the possibility, or at least the window of time for
>> which your object may be in an invalid state.
>> The fact that objects can be null, makes this problem more serious. Of
>> course, allowing nulls to exist in the language and the lack of
>> 'final' go hand in hand.
>> Does putting a final concept in the language sound like something that
>> would belong in Haxe?
>>
>> Does anyone have any workarounds to ensure that my data always is in a
>> state of integrity?
>>
>> Jordo
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Justin Donaldson-3
Here's more details on _init_:
http://haxe.org/doc/advanced/magic
I don't think it will help you...

It's an older "magic" function, which used to be the cool thing to abuse before macros came along.

-Justin

On Tue, Mar 22, 2011 at 6:15 AM, Hugh Sanderson <[hidden email]> wrote:
Hi,
Yes, I would really like to see the ability to init non-static member variables at
declaration time. It make so much sense.

Hugh


One solution would be to not forget initing them. You can do that with a
macro function called _init_ i think, which is called before everything else
automatically. So the problem resumes at not forgetting to use this
function.


On Tue, Mar 22, 2011 at 9:36 AM, Jordo Odroj <[hidden email]> wrote:

I've been running into a problem lately. The problem is that sometimes
I forget to initialize my member variables in the constructor. This
has caused me quite a lot of pain trying to come up with ways that
force members to be defined at construction time. In Java, there is a
final keyword, which will require that a final member has been
assigned at construction time.
This is very important for the following reason.

This eliminates the possibility, or at least the window of time for
which your object may be in an invalid state.
The fact that objects can be null, makes this problem more serious. Of
course, allowing nulls to exist in the language and the lack of
'final' go hand in hand.
Does putting a final concept in the language sound like something that
would belong in Haxe?

Does anyone have any workarounds to ensure that my data always is in a
state of integrity?

Jordo

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




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


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Paul Zirkle
In reply to this post by Gamehaxe
"I would really like to see the ability to init non-static member variables at
declaration time"

From a philosophic view, this obscures the fact that the initialization will happen repeatedly whenever an object is instantiated. 

But more importantly; you can already do this inside of the constructor for a non-static object.

I strongly suggest against being able to init non-static member variables in line with their declaration (like you can in Java) because this leads to multiple places where it can be initialized: in practice this means that programmers will sometimes initialize at the declaration, sometimes in the constructor, and sometimes not at all. And since member variables can be declared anywhere in a class definition, their initialization could happen at the top middle or bottom of the class-- so trying to find where a variable is being initialized requires you to scan the entire class definition!

I've had nightmares trying to convert Java classes to C++ in part due to this specific feature combined with bad programmer usage.

On Tue, Mar 22, 2011 at 3:15 AM, Hugh Sanderson <[hidden email]> wrote:
Hi,
Yes, I would really like to see the ability to init non-static member variables at
declaration time. It make so much sense.

Hugh


One solution would be to not forget initing them. You can do that with a
macro function called _init_ i think, which is called before everything else
automatically. So the problem resumes at not forgetting to use this
function.


On Tue, Mar 22, 2011 at 9:36 AM, Jordo Odroj <[hidden email]> wrote:

I've been running into a problem lately. The problem is that sometimes
I forget to initialize my member variables in the constructor. This
has caused me quite a lot of pain trying to come up with ways that
force members to be defined at construction time. In Java, there is a
final keyword, which will require that a final member has been
assigned at construction time.
This is very important for the following reason.

This eliminates the possibility, or at least the window of time for
which your object may be in an invalid state.
The fact that objects can be null, makes this problem more serious. Of
course, allowing nulls to exist in the language and the lack of
'final' go hand in hand.
Does putting a final concept in the language sound like something that
would belong in Haxe?

Does anyone have any workarounds to ensure that my data always is in a
state of integrity?

Jordo

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




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


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Nicolas Cannasse
Le 22/03/2011 21:03, Paul Zirkle a écrit :

> "I would really like to see the ability to init non-static member
> variables at
> declaration time"
>
>  From a philosophic view, this obscures the fact that the initialization
> will happen repeatedly whenever an object is instantiated.
>
> But more importantly; you can already do this inside of the constructor
> for a non-static object.
>
> I strongly suggest against being able to init non-static member
> variables in line with their declaration (like you can in Java) because
> this leads to multiple places where it can be initialized: in practice
> this means that programmers will sometimes initialize at the
> declaration, sometimes in the constructor, and sometimes not at all. And
> since member variables can be declared anywhere in a class definition,
> their initialization could happen at the top middle or bottom of the
> class-- so trying to find where a variable is being initialized requires
> you to scan the entire class definition!

I agree with this point of view, it is quite confusing to have several
places for initialization and the initialization order become unpredictable.

As for ensuring initialization, this is the same issue when asking for
not-nullable types : it's very hard to track down if/where something is
initialized or not in a OO language. This is the reason most
not-nullable type systems are in functional languages where mutability
and order of evaluation is much more strictly controlled.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Jordo Odroj
I would *never* suggest allowing two potential locations for initialization.
However, I *would* suggest that we require all members to be
explicitly assigned at construction time. This is a completely
different requirement.
I personally hate the concept of null as the ultimate subtype, but I
would be happy if the compiler forced us to set our values to
*something* even if they were null. This is so that at least the
compiler catches it, if you miss an assignment.

Like you said, if we allow assignment at *definition* time, that moves
in the opposite direction and makes it harder to catch bugs IMHO.

For the record, Java allows final members that aren't initialized at
definition, so long as you initialize them in the constructor, which
it does a great job of checking at compile time.
This is more like what I am suggesting.

On Tue, Mar 22, 2011 at 2:12 PM, Nicolas Cannasse
<[hidden email]> wrote:

> Le 22/03/2011 21:03, Paul Zirkle a écrit :
>>
>> "I would really like to see the ability to init non-static member
>> variables at
>> declaration time"
>>
>>  From a philosophic view, this obscures the fact that the initialization
>> will happen repeatedly whenever an object is instantiated.
>>
>> But more importantly; you can already do this inside of the constructor
>> for a non-static object.
>>
>> I strongly suggest against being able to init non-static member
>> variables in line with their declaration (like you can in Java) because
>> this leads to multiple places where it can be initialized: in practice
>> this means that programmers will sometimes initialize at the
>> declaration, sometimes in the constructor, and sometimes not at all. And
>> since member variables can be declared anywhere in a class definition,
>> their initialization could happen at the top middle or bottom of the
>> class-- so trying to find where a variable is being initialized requires
>> you to scan the entire class definition!
>
> I agree with this point of view, it is quite confusing to have several
> places for initialization and the initialization order become unpredictable.
>
> As for ensuring initialization, this is the same issue when asking for
> not-nullable types : it's very hard to track down if/where something is
> initialized or not in a OO language. This is the reason most not-nullable
> type systems are in functional languages where mutability and order of
> evaluation is much more strictly controlled.
>
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Gamehaxe
Hi,
I do not think "allowing two potential locations" is very
meaningful, because you can set the variables anywhere in the program,
ie infinite places.
What about local vars and static vars?  Should we remove the ability
to set static vars at declaration time and require an "init" function?

I remember a time in "C" when you could not initialize the vars
at declaration time.  What a pain the the ass - I could never go back.

There is a very real bug in physaxe caused by member variables
not being initilaized - which worked in flash, but neko treats these
as nulls.

I think initializing member vars at declaration is not only a
time saver, but also a best practice.  And you do not get many
free lunches like this in programming.

Hugh


> I would *never* suggest allowing two potential locations for  
> initialization.
> However, I *would* suggest that we require all members to be
> explicitly assigned at construction time. This is a completely
> different requirement.
> I personally hate the concept of null as the ultimate subtype, but I
> would be happy if the compiler forced us to set our values to
> *something* even if they were null. This is so that at least the
> compiler catches it, if you miss an assignment.
>
> Like you said, if we allow assignment at *definition* time, that moves
> in the opposite direction and makes it harder to catch bugs IMHO.
>
> For the record, Java allows final members that aren't initialized at
> definition, so long as you initialize them in the constructor, which
> it does a great job of checking at compile time.
> This is more like what I am suggesting.
>
> On Tue, Mar 22, 2011 at 2:12 PM, Nicolas Cannasse
> <[hidden email]> wrote:
>> Le 22/03/2011 21:03, Paul Zirkle a écrit :
>>>
>>> "I would really like to see the ability to init non-static member
>>> variables at
>>> declaration time"
>>>
>>>  From a philosophic view, this obscures the fact that the  
>>> initialization
>>> will happen repeatedly whenever an object is instantiated.
>>>
>>> But more importantly; you can already do this inside of the constructor
>>> for a non-static object.
>>>
>>> I strongly suggest against being able to init non-static member
>>> variables in line with their declaration (like you can in Java) because
>>> this leads to multiple places where it can be initialized: in practice
>>> this means that programmers will sometimes initialize at the
>>> declaration, sometimes in the constructor, and sometimes not at all.  
>>> And
>>> since member variables can be declared anywhere in a class definition,
>>> their initialization could happen at the top middle or bottom of the
>>> class-- so trying to find where a variable is being initialized  
>>> requires
>>> you to scan the entire class definition!
>>
>> I agree with this point of view, it is quite confusing to have several
>> places for initialization and the initialization order become  
>> unpredictable.
>>
>> As for ensuring initialization, this is the same issue when asking for
>> not-nullable types : it's very hard to track down if/where something is
>> initialized or not in a OO language. This is the reason most  
>> not-nullable
>> type systems are in functional languages where mutability and order of
>> evaluation is much more strictly controlled.
>>
>> Nicolas
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Cauê W.

2011/3/23 Hugh Sanderson <[hidden email]>

I think initializing member vars at declaration is not only a
time saver, but also a best practice.  And you do not get many
free lunches like this in programming.

I couldn't agree more. It feels natural, and when you are declaring a var you basically are thinking about it and how to initialize it.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Raoul Duke
In reply to this post by Jordo Odroj
On Wed, Mar 23, 2011 at 2:07 AM, Jordo Odroj <[hidden email]> wrote:
> I would *never* suggest allowing two potential locations for initialization.
> However, I *would* suggest that we require all members to be
> explicitly assigned at construction time. This is a completely
> different requirement.
> For the record, Java allows final members that aren't initialized at
> definition, so long as you initialize them in the constructor, which
> it does a great job of checking at compile time.
> This is more like what I am suggesting.

but i think java also allows you to initialize a final variable at
definition time so there are two potential locations for
initialization.

just pointing out that your holding up java as a good example must be
carefully done, i think. :-)

sincereley.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Jordo Odroj
I don't admire Java's ability to allow a variable to be initialized in
two places, but rather I admire it's ability to *require* that it be
initialized *by the time* the constructor completes.
This is what I desire in Haxe. That is more important than whether or
not you can initialize them at declaration time.
The declaration time feature - I don't feel strongly either way. If I
don't like it- I don't have to use it. But the feature that *I'm*
talking about is not about convenience, but rather about writing type
safe software that doesn't permit data to be in an invalid state.



On Wed, Mar 23, 2011 at 10:48 AM, Raoul Duke <[hidden email]> wrote:

> On Wed, Mar 23, 2011 at 2:07 AM, Jordo Odroj <[hidden email]> wrote:
>> I would *never* suggest allowing two potential locations for initialization.
>> However, I *would* suggest that we require all members to be
>> explicitly assigned at construction time. This is a completely
>> different requirement.
>> For the record, Java allows final members that aren't initialized at
>> definition, so long as you initialize them in the constructor, which
>> it does a great job of checking at compile time.
>> This is more like what I am suggesting.
>
> but i think java also allows you to initialize a final variable at
> definition time so there are two potential locations for
> initialization.
>
> just pointing out that your holding up java as a good example must be
> carefully done, i think. :-)
>
> sincereley.
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

Tarwin Stroh-Spijer
I think maybe an optional compiler warning would suffice. I do agree
that when you get lazy and let properties default ie a float to 0,
things can get unreadable for other people using your code.

On Wednesday, March 23, 2011, Jordo Odroj <[hidden email]> wrote:

> I don't admire Java's ability to allow a variable to be initialized in
> two places, but rather I admire it's ability to *require* that it be
> initialized *by the time* the constructor completes.
> This is what I desire in Haxe. That is more important than whether or
> not you can initialize them at declaration time.
> The declaration time feature - I don't feel strongly either way. If I
> don't like it- I don't have to use it. But the feature that *I'm*
> talking about is not about convenience, but rather about writing type
> safe software that doesn't permit data to be in an invalid state.
>
>
>
> On Wed, Mar 23, 2011 at 10:48 AM, Raoul Duke <[hidden email]> wrote:
>> On Wed, Mar 23, 2011 at 2:07 AM, Jordo Odroj <[hidden email]> wrote:
>>> I would *never* suggest allowing two potential locations for initialization.
>>> However, I *would* suggest that we require all members to be
>>> explicitly assigned at construction time. This is a completely
>>> different requirement.
>>> For the record, Java allows final members that aren't initialized at
>>> definition, so long as you initialize them in the constructor, which
>>> it does a great job of checking at compile time.
>>> This is more like what I am suggesting.
>>
>> but i think java also allows you to initialize a final variable at
>> definition time so there are two potential locations for
>> initialization.
>>
>> just pointing out that your holding up java as a good example must be
>> carefully done, i think. :-)
>>
>> sincereley.
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

David Peek
In reply to this post by Gamehaxe
Hi All,

Completely agree on this one, initialising vars where they're declared makes perfect sense to me.

I might also give you an opportunity consistency in the default value of certain types. An un-initialized int/bool vars currently return null on js/neko/php and 0/false on avm2/cpp. As you would be generating initialisers in the constructor at compile time, you could resolve these differences. Obviously people should initialise their vars, but consistent behavior if you don't would be a plus. It's also potentially confusing to people coming from languages where an int/bool being null is not possible ;)

One potential complication is what happens when you have getters/setters:
var prop(get_prop, set_prop):Int = 10;

Does that initialiser bypass the setter or not? My gut feeling would be yes, as you want this to be the default value for the property. There's actually an issue in the cpp that makes it impossible to bypass  the setter at all as even Reflect.setField(prop) calls it. On other targets if you want to initialise without calling the setter you must use Reflect.setField in the constructor. Initialising inline removes this inconvenience.

My 2 cents :)

Cheers,
David

On 23/03/2011, at 10:34 PM, Hugh Sanderson wrote:

> Hi,
> I do not think "allowing two potential locations" is very
> meaningful, because you can set the variables anywhere in the program,
> ie infinite places.
> What about local vars and static vars?  Should we remove the ability
> to set static vars at declaration time and require an "init" function?
>
> I remember a time in "C" when you could not initialize the vars
> at declaration time.  What a pain the the ass - I could never go back.
>
> There is a very real bug in physaxe caused by member variables
> not being initilaized - which worked in flash, but neko treats these
> as nulls.
>
> I think initializing member vars at declaration is not only a
> time saver, but also a best practice.  And you do not get many
> free lunches like this in programming.
>
> Hugh
>
>
>> I would *never* suggest allowing two potential locations for initialization.
>> However, I *would* suggest that we require all members to be
>> explicitly assigned at construction time. This is a completely
>> different requirement.
>> I personally hate the concept of null as the ultimate subtype, but I
>> would be happy if the compiler forced us to set our values to
>> *something* even if they were null. This is so that at least the
>> compiler catches it, if you miss an assignment.
>>
>> Like you said, if we allow assignment at *definition* time, that moves
>> in the opposite direction and makes it harder to catch bugs IMHO.
>>
>> For the record, Java allows final members that aren't initialized at
>> definition, so long as you initialize them in the constructor, which
>> it does a great job of checking at compile time.
>> This is more like what I am suggesting.
>>
>> On Tue, Mar 22, 2011 at 2:12 PM, Nicolas Cannasse
>> <[hidden email]> wrote:
>>> Le 22/03/2011 21:03, Paul Zirkle a écrit :
>>>>
>>>> "I would really like to see the ability to init non-static member
>>>> variables at
>>>> declaration time"
>>>>
>>>> From a philosophic view, this obscures the fact that the initialization
>>>> will happen repeatedly whenever an object is instantiated.
>>>>
>>>> But more importantly; you can already do this inside of the constructor
>>>> for a non-static object.
>>>>
>>>> I strongly suggest against being able to init non-static member
>>>> variables in line with their declaration (like you can in Java) because
>>>> this leads to multiple places where it can be initialized: in practice
>>>> this means that programmers will sometimes initialize at the
>>>> declaration, sometimes in the constructor, and sometimes not at all. And
>>>> since member variables can be declared anywhere in a class definition,
>>>> their initialization could happen at the top middle or bottom of the
>>>> class-- so trying to find where a variable is being initialized requires
>>>> you to scan the entire class definition!
>>>
>>> I agree with this point of view, it is quite confusing to have several
>>> places for initialization and the initialization order become unpredictable.
>>>
>>> As for ensuring initialization, this is the same issue when asking for
>>> not-nullable types : it's very hard to track down if/where something is
>>> initialized or not in a OO language. This is the reason most not-nullable
>>> type systems are in functional languages where mutability and order of
>>> evaluation is much more strictly controlled.
>>>
>>> Nicolas
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
> --
> haXe - an open source web programming language
> http://haxe.org

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

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Haxe - no final keyword. How do I ensure at compile time that my class has been initialized?

David Peek
In reply to this post by Gamehaxe
Hi All,

Completely agree on this one, initialising vars where they're declared makes perfect sense to me.

I might also give you an opportunity consistency in the default value of certain types. An un-initialized int/bool vars currently return null on js/neko/php and 0/false on avm2/cpp. As you would be generating initialisers in the constructor at compile time, you could resolve these differences. Obviously people should initialise their vars, but consistent behavior if you don't would be a plus. It's also potentially confusing to people coming from languages where an int/bool being null is not possible ;)

One potential complication is what happens when you have getters/setters:
var prop(get_prop, set_prop):Int = 10;

Does that initialiser bypass the setter or not? My gut feeling would be yes, as you want this to be the default value for the property. There's actually an issue in the cpp that makes it impossible to bypass the setter at all as even Reflect.setField(prop) calls it. On other targets if you want to initialise without calling the setter you must use Reflect.setField in the constructor. Initialising inline removes this inconvenience.

My 2 cents :)

Cheers,
David

On 23/03/2011, at 10:34 PM, Hugh Sanderson wrote:

> Hi,
> I do not think "allowing two potential locations" is very
> meaningful, because you can set the variables anywhere in the program,
> ie infinite places.
> What about local vars and static vars?  Should we remove the ability
> to set static vars at declaration time and require an "init" function?
>
> I remember a time in "C" when you could not initialize the vars
> at declaration time.  What a pain the the ass - I could never go back.
>
> There is a very real bug in physaxe caused by member variables
> not being initilaized - which worked in flash, but neko treats these
> as nulls.
>
> I think initializing member vars at declaration is not only a
> time saver, but also a best practice.  And you do not get many
> free lunches like this in programming.
>
> Hugh
>
>
>> I would *never* suggest allowing two potential locations for initialization.
>> However, I *would* suggest that we require all members to be
>> explicitly assigned at construction time. This is a completely
>> different requirement.
>> I personally hate the concept of null as the ultimate subtype, but I
>> would be happy if the compiler forced us to set our values to
>> *something* even if they were null. This is so that at least the
>> compiler catches it, if you miss an assignment.
>>
>> Like you said, if we allow assignment at *definition* time, that moves
>> in the opposite direction and makes it harder to catch bugs IMHO.
>>
>> For the record, Java allows final members that aren't initialized at
>> definition, so long as you initialize them in the constructor, which
>> it does a great job of checking at compile time.
>> This is more like what I am suggesting.
>>
>> On Tue, Mar 22, 2011 at 2:12 PM, Nicolas Cannasse
>> <[hidden email]> wrote:
>>> Le 22/03/2011 21:03, Paul Zirkle a écrit :
>>>>
>>>> "I would really like to see the ability to init non-static member
>>>> variables at
>>>> declaration time"
>>>>
>>>> From a philosophic view, this obscures the fact that the initialization
>>>> will happen repeatedly whenever an object is instantiated.
>>>>
>>>> But more importantly; you can already do this inside of the constructor
>>>> for a non-static object.
>>>>
>>>> I strongly suggest against being able to init non-static member
>>>> variables in line with their declaration (like you can in Java) because
>>>> this leads to multiple places where it can be initialized: in practice
>>>> this means that programmers will sometimes initialize at the
>>>> declaration, sometimes in the constructor, and sometimes not at all. And
>>>> since member variables can be declared anywhere in a class definition,
>>>> their initialization could happen at the top middle or bottom of the
>>>> class-- so trying to find where a variable is being initialized requires
>>>> you to scan the entire class definition!
>>>
>>> I agree with this point of view, it is quite confusing to have several
>>> places for initialization and the initialization order become unpredictable.
>>>
>>> As for ensuring initialization, this is the same issue when asking for
>>> not-nullable types : it's very hard to track down if/where something is
>>> initialized or not in a OO language. This is the reason most not-nullable
>>> type systems are in functional languages where mutability and order of
>>> evaluation is much more strictly controlled.
>>>
>>> Nicolas
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
> --
> haXe - an open source web programming language
> http://haxe.org


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