Same field name can't be use for both static and instance

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

Same field name can't be use for both static and instance

edA-qa mort-ora-y
Why was this limitation introduced in 2.03?

"Same field name can't be use for both static and instance"

It causes me a lot of grief and makes some of my classes inoperable in
the fashion I'd like them.

For example I have a Random class which has an instance form and a
static form.  The names of the functions, such as "nextBool" as the same
in both forms.  This limitation means I can't do that and am forced to
give them different names.


--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
        http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
        http://wiki.disemia.com/HaXe
       
A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Same field name can't be use for both static and instance

Nicolas Cannasse
edA-qa mort-ora-y a écrit :
> Why was this limitation introduced in 2.03?

In was changed in 2.04

> "Same field name can't be use for both static and instance"

Because several platforms have issues with it, so we discussed it with
Franco and Hugh and decided it was best to forbid it directly in the
language instead of having to deal with hackish workarounds.

Nicolas

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

Re: Same field name can't be use for both static and instance

Martijn Loots
On Thu, 30 Jul 2009, Nicolas Cannasse wrote:

> edA-qa mort-ora-y a écrit :
>> Why was this limitation introduced in 2.03?
>
> In was changed in 2.04
>
>> "Same field name can't be use for both static and instance"
>
> Because several platforms have issues with it, so we discussed it with Franco
> and Hugh and decided it was best to forbid it directly in the language
> instead of having to deal with hackish workarounds.
>
And the new using keyword makes it even harder to distinguish
between a static and an instance method... This enforces unique
names: better in this way.

--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )
--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Same field name can't be use for both static and instance

edA-qa mort-ora-y
Martijn Loots wrote:
> And the new using keyword makes it even harder to distinguish
> between a static and an instance method... This enforces unique
> names: better in this way.

I'm sure there is always a reason to make the changes.  But I'm always
very concerned that *every* upgrade I make of haxe, between minor
versions, or even CVS version, has introduced some backwards
incompatibility.

It's a serious problem with the language.



--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
        http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
        http://wiki.disemia.com/HaXe
       
A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Same field name can't be use for both static and instance

Pimm Hogeling
This is going a bit off-topic, but I think we should not focus on backwards-compatibility too much. Not in very specific cases like this one, at least. Five years from now I'd rather have a good language than one that is still compatible with all the code that is written this year, but is crappy.

If you are having serious problems compiling a project in the current haXe, revert to an older version.

On Thu, Jul 30, 2009 at 20:41, edA-qa mort-ora-y <[hidden email]> wrote:
Martijn Loots wrote:
> And the new using keyword makes it even harder to distinguish
> between a static and an instance method... This enforces unique
> names: better in this way.

I'm sure there is always a reason to make the changes.  But I'm always
very concerned that *every* upgrade I make of haxe, between minor
versions, or even CVS version, has introduced some backwards
incompatibility.

It's a serious problem with the language.



--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
       http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
       http://wiki.disemia.com/HaXe

A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


--
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
|

backwards incompatibility

edA-qa mort-ora-y
Pimm Hogeling wrote:
> This is going a bit off-topic, but I think we should not focus on
> backwards-compatibility too much. Not in very specific cases like this
> one, at least. Five years from now I'd rather have a good language than
> one that is still compatible with all the code that is written this
> year, but is crappy.

I find this is not a good approach.  Consider that all of the code
written in haxelib and online, unless actively maintained will be
useless within just a couple years.

Perhaps you have a somewhat nicer language, but at the cost of greatly
reducing your overall library and code base.

Newcomers to the language will inevitably find outdated examples and cod
which just doesn't compile anymore.  Worse, the code will compile but
just doesn't work anymore as originally intended.

Now, I know the runtime problems aren't always intentional.  But lacking
a good language spec and test library they are inevitable (as has proved
to be the case so far).

For planned incompatibilities there should be a very good reason, and it
must be detectable by the compiler and emit an error.

> If you are having serious problems compiling a project in the current
> haXe, revert to an older version.

That just pushes the problems off to another day -- and since there'll
be even more problems it seems prudent to do regularly rather than be
left with a mass of useless code.

--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
        http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
        http://wiki.disemia.com/HaXe
       
A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backwards incompatibility

Pimm Hogeling
edA-qa mort-ora-y wrote:
> Newcomers to the language will inevitably find outdated examples and cod
> which just doesn't compile anymore.  Worse, the code will compile but
> just doesn't work anymore as originally intended.
Always keeping your language backwards-compatible is not the solution to outdated examples, updating the examples is. I see your point, but I don't think we should use hacks to be able to have a static and a non-static method with the same name just because some people might do that, for example. The main focus should be a good language. I believe a newcomer benefits more from a good language than from examples that still have references to dinosaurs in them, but still compile.

> [Using an old haXe version] just pushes the problems off to another day
> -- and since there'll be even more problems it seems prudent to do regularly
> rather than be left with a mass of useless code.
True. I'm not saying people should use old versions for production. But if you are maintaining an older application, I don't see why you shouldn't use an older compiler instead of porting everything. Again, I'm not saying people should actively develop in older versions of a language, think of all the bugfixes you'd miss!

On Thu, Jul 30, 2009 at 21:13, edA-qa mort-ora-y <[hidden email]> wrote:
Pimm Hogeling wrote:
> This is going a bit off-topic, but I think we should not focus on
> backwards-compatibility too much. Not in very specific cases like this
> one, at least. Five years from now I'd rather have a good language than
> one that is still compatible with all the code that is written this
> year, but is crappy.

I find this is not a good approach.  Consider that all of the code
written in haxelib and online, unless actively maintained will be
useless within just a couple years.

Perhaps you have a somewhat nicer language, but at the cost of greatly
reducing your overall library and code base.

Newcomers to the language will inevitably find outdated examples and cod
which just doesn't compile anymore.  Worse, the code will compile but
just doesn't work anymore as originally intended.

Now, I know the runtime problems aren't always intentional.  But lacking
a good language spec and test library they are inevitable (as has proved
to be the case so far).

For planned incompatibilities there should be a very good reason, and it
must be detectable by the compiler and emit an error.

> If you are having serious problems compiling a project in the current
> haXe, revert to an older version.

That just pushes the problems off to another day -- and since there'll
be even more problems it seems prudent to do regularly rather than be
left with a mass of useless code.

--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
       http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
       http://wiki.disemia.com/HaXe

A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


--
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: backwards incompatibility

Mark de Bruijn | Dykam
And yeah, another point of view.

// some basic talk
Both are partly right, in my point of view. Backwards compatibility is a great good, which must be used wherever possible. Especially with languages where libraries are code based, not precompiled, backward compatibility makes sure these will and will stay to work. But it also blocks important progress. From this mailing, I see massive breaking changes are introduced in just one subversion of haXe. I don't find that right. This had to be done in 1 to 2, not in 2.03 to 2.04. These small numbers mean, small changes. Not complete lib breaking stuff.

If I were the code managed, I had pushed this change forward, or released an new version of haXe. or change the numbering from *.* to *.*, as the .* currently doesn't say what size the change is, breaking features with it.

On Thu, Jul 30, 2009 at 9:28 PM, Pimm Hogeling <[hidden email]> wrote:
edA-qa mort-ora-y wrote:
> Newcomers to the language will inevitably find outdated examples and cod
> which just doesn't compile anymore.  Worse, the code will compile but
> just doesn't work anymore as originally intended.
Always keeping your language backwards-compatible is not the solution to outdated examples, updating the examples is. I see your point, but I don't think we should use hacks to be able to have a static and a non-static method with the same name just because some people might do that, for example. The main focus should be a good language. I believe a newcomer benefits more from a good language than from examples that still have references to dinosaurs in them, but still compile.

> [Using an old haXe version] just pushes the problems off to another day

> -- and since there'll be even more problems it seems prudent to do regularly
> rather than be left with a mass of useless code.
True. I'm not saying people should use old versions for production. But if you are maintaining an older application, I don't see why you shouldn't use an older compiler instead of porting everything. Again, I'm not saying people should actively develop in older versions of a language, think of all the bugfixes you'd miss!

On Thu, Jul 30, 2009 at 21:13, edA-qa mort-ora-y <[hidden email]> wrote:
Pimm Hogeling wrote:
> This is going a bit off-topic, but I think we should not focus on
> backwards-compatibility too much. Not in very specific cases like this
> one, at least. Five years from now I'd rather have a good language than
> one that is still compatible with all the code that is written this
> year, but is crappy.

I find this is not a good approach.  Consider that all of the code
written in haxelib and online, unless actively maintained will be
useless within just a couple years.

Perhaps you have a somewhat nicer language, but at the cost of greatly
reducing your overall library and code base.

Newcomers to the language will inevitably find outdated examples and cod
which just doesn't compile anymore.  Worse, the code will compile but
just doesn't work anymore as originally intended.

Now, I know the runtime problems aren't always intentional.  But lacking
a good language spec and test library they are inevitable (as has proved
to be the case so far).

For planned incompatibilities there should be a very good reason, and it
must be detectable by the compiler and emit an error.

> If you are having serious problems compiling a project in the current
> haXe, revert to an older version.

That just pushes the problems off to another day -- and since there'll
be even more problems it seems prudent to do regularly rather than be
left with a mass of useless code.

--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
       http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
       http://wiki.disemia.com/HaXe

A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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


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



--
Mark

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

Re: backwards incompatibility

Nathan Rixham
bc or rapid release of stunning new features? no brainer imho I'm sure
we can all live with bc breaks whilst the language evolves and matures;
obviously no need to break bc out of lazyness but all in it'd be great
to have haxe go for another few releases before getting it too QA/design
by committee.

Anytime this kind of thing is mentioned i have visions of PHP land - you
know where you wait for 3 years to see a change that's minute in
comparison to the changes rolled out by nic and co.

i mean look at the features added in 2.04 - have you ever seen a jump
like that in even 2/3 major versions of any other language??


Mark de Bruijn wrote:

> And yeah, another point of view.
> // some basic talk
> Both are partly right, in my point of view. Backwards compatibility is a
> great good, which must be used wherever possible. Especially with languages
> where libraries are code based, not precompiled,
> backward compatibility makes sure these will and will stay to work. But it
> also blocks important progress. From this mailing, I see massive breaking
> changes are introduced in just one subversion of haXe. I don't find that
> right. This had to be done in 1 to 2, not in 2.03 to 2.04. These small
> numbers mean, small changes. Not complete lib breaking stuff.
>
> If I were the code managed, I had pushed this change forward, or released an
> new version of haXe. or change the numbering from *.* to *.*, as the .*
> currently doesn't say what size the change is, breaking features with it.
>
> On Thu, Jul 30, 2009 at 9:28 PM, Pimm Hogeling <[hidden email]>wrote:
>
>> edA-qa mort-ora-y wrote:
>>> Newcomers to the language will inevitably find outdated examples and cod
>>> which just doesn't compile anymore.  Worse, the code will compile but
>>> just doesn't work anymore as originally intended.
>> Always keeping your language backwards-compatible is not the solution to
>> outdated examples, updating the examples is. I see your point, but I don't
>> think we should use hacks to be able to have a static and a non-static
>> method with the same name just because some people might do that, for
>> example. The main focus should be a good language. I believe a newcomer
>> benefits more from a good language than from examples that still have
>> references to dinosaurs in them, but still compile.
>>
>>> [Using an old haXe version] just pushes the problems off to another day
>>> -- and since there'll be even more problems it seems prudent to do
>> regularly
>>> rather than be left with a mass of useless code.
>> True. I'm not saying people should use old versions for production. But if
>> you are maintaining an older application, I don't see why you shouldn't use
>> an older compiler instead of porting everything. Again, I'm not saying
>> people should actively develop in older versions of a language, think of all
>> the bugfixes you'd miss!
>>
>> On Thu, Jul 30, 2009 at 21:13, edA-qa mort-ora-y <[hidden email]>wrote:
>>
>>> Pimm Hogeling wrote:
>>>> This is going a bit off-topic, but I think we should not focus on
>>>> backwards-compatibility too much. Not in very specific cases like this
>>>> one, at least. Five years from now I'd rather have a good language than
>>>> one that is still compatible with all the code that is written this
>>>> year, but is crappy.
>>> I find this is not a good approach.  Consider that all of the code
>>> written in haxelib and online, unless actively maintained will be
>>> useless within just a couple years.
>>>
>>> Perhaps you have a somewhat nicer language, but at the cost of greatly
>>> reducing your overall library and code base.
>>>
>>> Newcomers to the language will inevitably find outdated examples and cod
>>> which just doesn't compile anymore.  Worse, the code will compile but
>>> just doesn't work anymore as originally intended.
>>>
>>> Now, I know the runtime problems aren't always intentional.  But lacking
>>> a good language spec and test library they are inevitable (as has proved
>>> to be the case so far).
>>>
>>> For planned incompatibilities there should be a very good reason, and it
>>> must be detectable by the compiler and emit an error.
>>>
>>>> If you are having serious problems compiling a project in the current
>>>> haXe, revert to an older version.
>>> That just pushes the problems off to another day -- and since there'll
>>> be even more problems it seems prudent to do regularly rather than be
>>> left with a mass of useless code.
>>>
>>> --
>>> edA-qa mort-ora-y
>>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>
>>> BigTPoker uses haXe and DHLIB
>>>        http://BigTPoker.com/?source=haxe-list
>>>
>>> The dis-Emi-A haXe Library
>>>        http://wiki.disemia.com/HaXe
>>>
>>> A full set of tools, classes, and support facilities aimed at
>>> simplifying and expediting game creation in Flash 9.
>>>
>>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> Sign: Please digitally sign your emails.
>>> Encrypt: I'm also happy to receive encrypted mail.
>>>
>>>
>>> --
>>> 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: backwards incompatibility

edA-qa mort-ora-y
Nathan Rixham wrote:
> Anytime this kind of thing is mentioned i have visions of PHP land - you
> know where you wait for 3 years to see a change that's minute in
> comparison to the changes rolled out by nic and co.

Yet PHP has a *massive* library which has stayed compatible for a long
time. Even with the breaks in compatibility they allowed the old code to
work as is.

> i mean look at the features added in 2.04 - have you ever seen a jump
> like that in even 2/3 major versions of any other language??

No.  And for that reason my C++ code I wrote 10 years ago still compiles
fine today.

--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
        http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
        http://wiki.disemia.com/HaXe
       
A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backwards incompatibility

Nathan Rixham
edA-qa mort-ora-y wrote:

> Nathan Rixham wrote:
>> Anytime this kind of thing is mentioned i have visions of PHP land - you
>> know where you wait for 3 years to see a change that's minute in
>> comparison to the changes rolled out by nic and co.
>
> Yet PHP has a *massive* library which has stayed compatible for a long
> time. Even with the breaks in compatibility they allowed the old code to
> work as is.
>
>> i mean look at the features added in 2.04 - have you ever seen a jump
>> like that in even 2/3 major versions of any other language??
>
> No.  And for that reason my C++ code I wrote 10 years ago still compiles
> fine today.
>
>

but does your php 1/2/3 code work fine today...

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

Re: backwards incompatibility

Nathan Rixham
In reply to this post by edA-qa mort-ora-y
edA-qa mort-ora-y wrote:

> Nathan Rixham wrote:
>> Anytime this kind of thing is mentioned i have visions of PHP land - you
>> know where you wait for 3 years to see a change that's minute in
>> comparison to the changes rolled out by nic and co.
>
> Yet PHP has a *massive* library which has stayed compatible for a long
> time. Even with the breaks in compatibility they allowed the old code to
> work as is.
>
>> i mean look at the features added in 2.04 - have you ever seen a jump
>> like that in even 2/3 major versions of any other language??
>
> No.  And for that reason my C++ code I wrote 10 years ago still compiles
> fine today.
>
>

actually.. to be blunt

if you want enterprise level solid reliability and code, then do what
the rest of us do and use a major language or come back in a few
months/years

but if you want something that is at the cutting edge, breaking massive
boundaries never done before, growing from strength to strength and
becoming easily the best language for dev's thus far then stick around
and enjoy the ride.

don't f up the first decent progress we've seen in the web dev arena
*ever* over ridiculous things like bc, please, really, you any idea how
long most of the dev community has waited for something like this?? -
the features and libs are rolling out faster than anybody can keep up,
don't know about you but I get the feeling everybody involved in and
using haxe is just on one great big learning & development curve at the
minute, once that's been exhausted then worry about bc, documentation
and all the stuff that slows down progress (but makes the product of
that progress usable)

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

Re: backwards incompatibility

Lee Sylvester
Another way to look at it is to allow the creatives the freedom to
create what they will, and then invite those that enjoy writing
documentation to come along and write it. I've had my fill of
documenting for the time being ;-) so I'm looking to create video
tutorials next (still planning them), but that doesn't stop others from
taking the bull by the horns and whipping out some much needed reading
material.

In short; stop bitching and get doing!  ;-)

haXe is still really young. It's like a super Eden that's still forming
with huge mountainous frameworks still finding their place and gushes of
functionality rushing from the crevices of peoples imaginations. As
Nathan said, this will slow down eventually, but for the time being it
needs to be nurtured. For as a child, once it's matured, it's a slow
journey to its eventual and ever inevitable death.

Lee



Nathan Rixham wrote:

> edA-qa mort-ora-y wrote:
>> Nathan Rixham wrote:
>>> Anytime this kind of thing is mentioned i have visions of PHP land -
>>> you
>>> know where you wait for 3 years to see a change that's minute in
>>> comparison to the changes rolled out by nic and co.
>>
>> Yet PHP has a *massive* library which has stayed compatible for a long
>> time. Even with the breaks in compatibility they allowed the old code to
>> work as is.
>>
>>> i mean look at the features added in 2.04 - have you ever seen a jump
>>> like that in even 2/3 major versions of any other language??
>>
>> No.  And for that reason my C++ code I wrote 10 years ago still compiles
>> fine today.
>>
>>
>
> actually.. to be blunt
>
> if you want enterprise level solid reliability and code, then do what
> the rest of us do and use a major language or come back in a few
> months/years
>
> but if you want something that is at the cutting edge, breaking
> massive boundaries never done before, growing from strength to
> strength and becoming easily the best language for dev's thus far then
> stick around and enjoy the ride.
>
> don't f up the first decent progress we've seen in the web dev arena
> *ever* over ridiculous things like bc, please, really, you any idea
> how long most of the dev community has waited for something like
> this?? - the features and libs are rolling out faster than anybody can
> keep up, don't know about you but I get the feeling everybody involved
> in and using haxe is just on one great big learning & development
> curve at the minute, once that's been exhausted then worry about bc,
> documentation and all the stuff that slows down progress (but makes
> the product of that progress usable)
>


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

Re: backwards incompatibility

jlm@justinfront.net
In reply to this post by Mark de Bruijn | Dykam
Just throwing some ideas out there...

Would a compiler flag be possible to implement... so that some changes could be reversed so haXeLibs would still work till updated? Probably not.. but if can easy?

away team have a visual test system that allows them to test code results visually would this help test new releases of haXe, maybe possible for haXe lib users to submit tests both visually or otherwise? I am sure there is not a problem with how its tested at the moment, but knowing that ASwing was broken awhile back would be useful for a new user and if that can be checked with an automated pre-release check, I don't see this as holding back progress if they can be implemented in a way as simple as submitting haXeLib.  
Something like "haxeTest" - but no idea how you might create it... but i guess it would be some sort of unit test?

Cheers

;j

On 30 Jul 2009, at 21:07, Mark de Bruijn wrote:

And yeah, another point of view.

// some basic talk
Both are partly right, in my point of view. Backwards compatibility is a great good, which must be used wherever possible. Especially with languages where libraries are code based, not precompiled, backward compatibility makes sure these will and will stay to work. But it also blocks important progress. From this mailing, I see massive breaking changes are introduced in just one subversion of haXe. I don't find that right. This had to be done in 1 to 2, not in 2.03 to 2.04. These small numbers mean, small changes. Not complete lib breaking stuff.

If I were the code managed, I had pushed this change forward, or released an new version of haXe. or change the numbering from *.* to *.*, as the .* currently doesn't say what size the change is, breaking features with it.

On Thu, Jul 30, 2009 at 9:28 PM, Pimm Hogeling <[hidden email]> wrote:
edA-qa mort-ora-y wrote:
> Newcomers to the language will inevitably find outdated examples and cod
> which just doesn't compile anymore.  Worse, the code will compile but
> just doesn't work anymore as originally intended.
Always keeping your language backwards-compatible is not the solution to outdated examples, updating the examples is. I see your point, but I don't think we should use hacks to be able to have a static and a non-static method with the same name just because some people might do that, for example. The main focus should be a good language. I believe a newcomer benefits more from a good language than from examples that still have references to dinosaurs in them, but still compile.

> [Using an old haXe version] just pushes the problems off to another day

> -- and since there'll be even more problems it seems prudent to do regularly
> rather than be left with a mass of useless code.
True. I'm not saying people should use old versions for production. But if you are maintaining an older application, I don't see why you shouldn't use an older compiler instead of porting everything. Again, I'm not saying people should actively develop in older versions of a language, think of all the bugfixes you'd miss!

On Thu, Jul 30, 2009 at 21:13, edA-qa mort-ora-y <[hidden email]> wrote:
Pimm Hogeling wrote:
> This is going a bit off-topic, but I think we should not focus on
> backwards-compatibility too much. Not in very specific cases like this
> one, at least. Five years from now I'd rather have a good language than
> one that is still compatible with all the code that is written this
> year, but is crappy.

I find this is not a good approach.  Consider that all of the code
written in haxelib and online, unless actively maintained will be
useless within just a couple years.

Perhaps you have a somewhat nicer language, but at the cost of greatly
reducing your overall library and code base.

Newcomers to the language will inevitably find outdated examples and cod
which just doesn't compile anymore.  Worse, the code will compile but
just doesn't work anymore as originally intended.

Now, I know the runtime problems aren't always intentional.  But lacking
a good language spec and test library they are inevitable (as has proved
to be the case so far).

For planned incompatibilities there should be a very good reason, and it
must be detectable by the compiler and emit an error.

> If you are having serious problems compiling a project in the current
> haXe, revert to an older version.

That just pushes the problems off to another day -- and since there'll
be even more problems it seems prudent to do regularly rather than be
left with a mass of useless code.

--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
       http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
       http://wiki.disemia.com/HaXe

A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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


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



--
Mark
--
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: backwards incompatibility

edA-qa mort-ora-y
In reply to this post by Nathan Rixham
Nathan Rixham wrote:
> ridiculous things like bc

That seems like a rather extreme position.


BTW, it's not new language *features* which are breaking my code at the
moment.  I have no idea how to fix the one I'm getting now.  I'm happy
to go along for the ride in the interest of getting a better compiler
and language.  But you see, upgrading is a major hassle for me.  The
types of errors I get aren't simply compiler errors or syntax changes.

My code *BREAKS* and I'm forced to debug and figure out what in the
upgrade broke it.

--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
        http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
        http://wiki.disemia.com/HaXe
       
A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backwards incompatibility

Martijn Loots
On Thu, 30 Jul 2009, edA-qa mort-ora-y wrote:

> Nathan Rixham wrote:
>> ridiculous things like bc
>
> My code *BREAKS* and I'm forced to debug and figure out what in the
> upgrade broke it.
>
Mmm, not saying that haXe is perfect, but normally if I see *this*
after an upgrade of a dev. tool, it turns out to be an undiscovered
bug that just now shows it ugly head for the first time...

Whish you luck though.

For me, I'd hate to see haXe maturing slower just because of rigid
enforcement of backward compatibility.

Nicolas every once in a while shows that he *does* have a proper
insight in bc importance as a reply on some feature request. I
trust that code breaks will be fewer and fewer as time goes by,
but that if they appear, there's a good reason for it.

Grtz,
--
-Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
-          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
-         ( >__< )  ----------------------------------------
-         ^^^  ^^^  (   Netwerken, Security, Open Source   )

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

Re: backwards incompatibility

Benjamin Dasnois
Hi,

haXe is Open Source, Open Source loves short release cycles, haXe has
short release cycles, all is good...

Let's be honest! Why the hell do you upgrade your compiler if you
think that it's breaking your code?!! Nothing prevents you from
keeping this version of the compiler on your computer...

I don't get why you guys complain, version management of dev tools is
something devs should have in mind... I'm sorry to say that if you
don't have that in mind, then you're a bad dev because you don't
understand the main concept of versionning.

Sure when a bug is introduced one should try to correct it, but when
compatibility is broken to allow the evolution of the language, it's
just a good thing.

PHP, although it's now quite old, still has a poor OO paradigm (try to
call a method on an object retrieved from an array directly... I'm
sure you will enjoy it!!)

haXe, as it is now, is a fast evolving language, that's what allows it
to give you all the cool features you get with it. Come and see what
was available in the early releases! If you fear that much that your
code breaks, just take a version of the compiler and stick with it,
that's not gonna break execution in the end...

ed, your code certainly breaks because of new features that at some
points required tweaking in the compiler. That's it. It's great that
you say that there's a new bug, but once you did : either you fix it,
either one fixes it, either you stick with a previous version of the
compiler for that code or you find a workaround. It's that simple.

There's absolutely no reason to be arguing about that...

Sorry if I seem a bit rude but I see *NO* point in this kind of
complain, but if there's one, please tell me.

Regards,

On Thu, Jul 30, 2009 at 11:57 PM, Martijn Loots<[hidden email]> wrote:

> On Thu, 30 Jul 2009, edA-qa mort-ora-y wrote:
>
>> Nathan Rixham wrote:
>>>
>>> ridiculous things like bc
>>
>> My code *BREAKS* and I'm forced to debug and figure out what in the
>> upgrade broke it.
>>
> Mmm, not saying that haXe is perfect, but normally if I see *this*
> after an upgrade of a dev. tool, it turns out to be an undiscovered
> bug that just now shows it ugly head for the first time...
>
> Whish you luck though.
>
> For me, I'd hate to see haXe maturing slower just because of rigid
> enforcement of backward compatibility.
>
> Nicolas every once in a while shows that he *does* have a proper
> insight in bc importance as a reply on some feature request. I
> trust that code breaks will be fewer and fewer as time goes by,
> but that if they appear, there's a good reason for it.
>
> Grtz,
> --
> -Martijn    @..@    ( Martijn Loots       -  Hengelo  [NL] )
> -          (`--')   ( martijn<@>cosix.com -  www.cosix.com )
> -         ( >__< )  ----------------------------------------
> -         ^^^  ^^^  (   Netwerken, Security, Open Source   )
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
DASNOIS Benjamin
http://www.benjamindasnois.com

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

Re: backwards incompatibility

Ron Wheeler
In reply to this post by Lee Sylvester
Lee McColl Sylvester wrote:

> Another way to look at it is to allow the creatives the freedom to
> create what they will, and then invite those that enjoy writing
> documentation to come along and write it. I've had my fill of
> documenting for the time being ;-) so I'm looking to create video
> tutorials next (still planning them), but that doesn't stop others
> from taking the bull by the horns and whipping out some much needed
> reading material.
>
> In short; stop bitching and get doing!  ;-)
>
> haXe is still really young. It's like a super Eden that's still
> forming with huge mountainous frameworks still finding their place and
> gushes of functionality rushing from the crevices of peoples
> imaginations. As Nathan said, this will slow down eventually, but for
> the time being it needs to be nurtured. For as a child, once it's
> matured, it's a slow journey to its eventual and ever inevitable death.
At some point, haXe will have to start to respect the installed base and
either provide backwards compatibility or wait before adding new feature
and in the interim warn programmers that they are using a function that
will be dropped or changed in subsequent releases. This seems to be the
usual practice and it allows programmers to move to the new release and
start to plan how to modernize their code to prepare for subsequent
releases.
Once this happens we will know that haXe is really ready for production
use in critical systems.

Ron

>
> Lee
>
>
>
> Nathan Rixham wrote:
>> edA-qa mort-ora-y wrote:
>>> Nathan Rixham wrote:
>>>> Anytime this kind of thing is mentioned i have visions of PHP land
>>>> - you
>>>> know where you wait for 3 years to see a change that's minute in
>>>> comparison to the changes rolled out by nic and co.
>>>
>>> Yet PHP has a *massive* library which has stayed compatible for a long
>>> time. Even with the breaks in compatibility they allowed the old
>>> code to
>>> work as is.
>>>
>>>> i mean look at the features added in 2.04 - have you ever seen a jump
>>>> like that in even 2/3 major versions of any other language??
>>>
>>> No.  And for that reason my C++ code I wrote 10 years ago still
>>> compiles
>>> fine today.
>>>
>>>
>>
>> actually.. to be blunt
>>
>> if you want enterprise level solid reliability and code, then do what
>> the rest of us do and use a major language or come back in a few
>> months/years
>>
>> but if you want something that is at the cutting edge, breaking
>> massive boundaries never done before, growing from strength to
>> strength and becoming easily the best language for dev's thus far
>> then stick around and enjoy the ride.
>>
>> don't f up the first decent progress we've seen in the web dev arena
>> *ever* over ridiculous things like bc, please, really, you any idea
>> how long most of the dev community has waited for something like
>> this?? - the features and libs are rolling out faster than anybody
>> can keep up, don't know about you but I get the feeling everybody
>> involved in and using haxe is just on one great big learning &
>> development curve at the minute, once that's been exhausted then
>> worry about bc, documentation and all the stuff that slows down
>> progress (but makes the product of that progress usable)
>>
>
>


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

Re: backwards incompatibility

edA-qa mort-ora-y
In reply to this post by Benjamin Dasnois
Benjamin Dasnois wrote:
> I don't get why you guys complain, version management of dev tools is
> something devs should have in mind... I'm sorry to say that if you
> don't have that in mind, then you're a bad dev because you don't
> understand the main concept of versionning.

Perhaps it is getting to a time when version management should be
considered.  I'm all in favour of the language evolving, but at the same
time I think there needs to be a stable branch available.

Consider my position, I've written a rather large library, and I have a
significant new website using haXe.  When somebody asks me what language
I use, I say haXe.  Do I recommend it?  Well, that's hard to do.  I
really enjoy using the language and though it is quite annoying to
upgrade I always do it.  But I can't recommend it to other people.

That's not a position that is good for haXe.  We really want that
everybody developer can say, "There is nothing else I'd consider."

> Sure when a bug is introduced one should try to correct it, but when
> compatibility is broken to allow the evolution of the language, it's

Again, I'm all for changes.  And any planned deprecation I actually
think is okay.  Though I think it should happen on a branch.  One is
forced to upgrade to get a lot of bug fixes, but at the same time is
stuck with all the new features.  Why not a branch which has just the
bug fixes.

Let's have a 3.0 unstable branch which is a free-for-all and a 2.0
branch which is simply a stable branch with bug-fixes ported back.

Additionally I think a test library is required at this point. I feel
too often that my code serves as the largest test base for the new haxe
versions.

> PHP, although it's now quite old, still has a poor OO paradigm (try to
> call a method on an object retrieved from an array directly... I'm

I mentioned PHP only for its abundant libraries.  Otherwise my
impression of PHP is very low.  Nonetheless I wouldn't consider using
any other language for server-side development of a web application.


--
edA-qa mort-ora-y
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

BigTPoker uses haXe and DHLIB
        http://BigTPoker.com/?source=haxe-list

The dis-Emi-A haXe Library
        http://wiki.disemia.com/HaXe
       
A full set of tools, classes, and support facilities aimed at
simplifying and expediting game creation in Flash 9.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sign: Please digitally sign your emails.
Encrypt: I'm also happy to receive encrypted mail.


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

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backwards incompatibility

James W. Hofmann
Quoting "edA-qa mort-ora-y" <[hidden email]>:

> Additionally I think a test library is required at this point. I feel
> too often that my code serves as the largest test base for the new haxe
> versions.

That indicates that your code is doing things far above and beyond  
what other people are doing with the language, and you are the one in  
the best position to write the tests. After all, most of us never use  
the entire language but just subsets :)


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