Standard library as haxelib

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

Standard library as haxelib

Michiel Crefcoeur
I think that every haxe user that's familiar with haxelib has asked him-/herself the question:
"Why isn't the standard library (std) a haxelib?"

Ofcourse, the answer would be that haxelib wasn't around when the standard library was first released.

But now that we have haxelib, is there any reason not to move the standard library to haxelib?

These are some of the pro's:
  • the compiler and the standard library can have seperate release schedules
  • the standard library can be split up into seperate libraries, every library having it's own dedicated team of haxers maintaining it
  • haxelib has versioning so updates won't break code written for a previous version of the standard library. In this situation, updates to the standard library can take place more often (think patches, bugfixes etc.)
  • makes it much more easy to write cross-target code: libraries can be split up in targets so C++ specialists work on the cpp version of te library while Flash Guru's work on the flash version of the library etc...
  • It's up to the user to decide which packages are available by default: effectively, there would be no more standard library, just standardized patterns/presets for effectively developing certain programs per target, which, to me, seems like a good thing

I don't think this would break any existing code, the compiler only needs an (or some) extra library argument(s). For projects that were written on the standard library one only needs to supply one extra library argument to the compiler to load the haxe standard library which groups all the seperate libraries (as requirements) to form the "deprecated" std lib.

So, is this transition part of the haxe roadmap yet and if so, how soon could we expect it?

Another thing that would be cool is if the compiler would automatically install haxelibs that aren't locally available (after the user confirms) when you try to compile a haxe project. You could argue that this should be taken care of by the IDE (it would probably be really easy to add this to FlashDevelop) but I believe this compiler-to-haxelib link is too obvious not to add to haXe! :-)

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

Re: Standard library as haxelib

Cauê W.
wow, I couldn't agree more.
Also having the standard libs more accessible for modifications and updates would result in a language with much more contributors.

Maybe we could release a haxe-std extension in the haxelib?

cheers
Cauê

2010/4/21 Michiel Crefcoeur <[hidden email]>
I think that every haxe user that's familiar with haxelib has asked him-/herself the question:
"Why isn't the standard library (std) a haxelib?"

Ofcourse, the answer would be that haxelib wasn't around when the standard library was first released.

But now that we have haxelib, is there any reason not to move the standard library to haxelib?

These are some of the pro's:
  • the compiler and the standard library can have seperate release schedules
  • the standard library can be split up into seperate libraries, every library having it's own dedicated team of haxers maintaining it
  • haxelib has versioning so updates won't break code written for a previous version of the standard library. In this situation, updates to the standard library can take place more often (think patches, bugfixes etc.)
  • makes it much more easy to write cross-target code: libraries can be split up in targets so C++ specialists work on the cpp version of te library while Flash Guru's work on the flash version of the library etc...
  • It's up to the user to decide which packages are available by default: effectively, there would be no more standard library, just standardized patterns/presets for effectively developing certain programs per target, which, to me, seems like a good thing

I don't think this would break any existing code, the compiler only needs an (or some) extra library argument(s). For projects that were written on the standard library one only needs to supply one extra library argument to the compiler to load the haxe standard library which groups all the seperate libraries (as requirements) to form the "deprecated" std lib.

So, is this transition part of the haxe roadmap yet and if so, how soon could we expect it?

Another thing that would be cool is if the compiler would automatically install haxelibs that aren't locally available (after the user confirms) when you try to compile a haxe project. You could argue that this should be taken care of by the IDE (it would probably be really easy to add this to FlashDevelop) but I believe this compiler-to-haxelib link is too obvious not to add to haXe! :-)

--
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: Standard library as haxelib

Baluta Cristian
Seems to me too complex for a beginner to download the lib. Maybe a feature to be able to replace them.

On Thu, Apr 22, 2010 at 5:51 AM, Cauê Waneck <[hidden email]> wrote:
wow, I couldn't agree more.
Also having the standard libs more accessible for modifications and updates would result in a language with much more contributors.

Maybe we could release a haxe-std extension in the haxelib?

cheers
Cauê

2010/4/21 Michiel Crefcoeur <[hidden email]>
I think that every haxe user that's familiar with haxelib has asked him-/herself the question:
"Why isn't the standard library (std) a haxelib?"

Ofcourse, the answer would be that haxelib wasn't around when the standard library was first released.

But now that we have haxelib, is there any reason not to move the standard library to haxelib?

These are some of the pro's:
  • the compiler and the standard library can have seperate release schedules
  • the standard library can be split up into seperate libraries, every library having it's own dedicated team of haxers maintaining it
  • haxelib has versioning so updates won't break code written for a previous version of the standard library. In this situation, updates to the standard library can take place more often (think patches, bugfixes etc.)
  • makes it much more easy to write cross-target code: libraries can be split up in targets so C++ specialists work on the cpp version of te library while Flash Guru's work on the flash version of the library etc...
  • It's up to the user to decide which packages are available by default: effectively, there would be no more standard library, just standardized patterns/presets for effectively developing certain programs per target, which, to me, seems like a good thing

I don't think this would break any existing code, the compiler only needs an (or some) extra library argument(s). For projects that were written on the standard library one only needs to supply one extra library argument to the compiler to load the haxe standard library which groups all the seperate libraries (as requirements) to form the "deprecated" std lib.

So, is this transition part of the haxe roadmap yet and if so, how soon could we expect it?

Another thing that would be cool is if the compiler would automatically install haxelibs that aren't locally available (after the user confirms) when you try to compile a haxe project. You could argue that this should be taken care of by the IDE (it would probably be really easy to add this to FlashDevelop) but I believe this compiler-to-haxelib link is too obvious not to add to haXe! :-)

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


--
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: Standard library as haxelib

edA-qa mort-ora-y
In reply to this post by Michiel Crefcoeur
Michiel Crefcoeur wrote:
> I think that every haxe user that's familiar with haxelib has asked
> him-/herself the question:
> "Why isn't the standard library (std) a haxelib?"

I don't like the idea of decentralizing the control of the standard
library. I would always like to know there is at least one common API
that works consistently between releases without too many modifications.
Similarily I'd like to know that when new language features appear, or
the compiler changes, that the standard library is properly adapted at
the same time.

I'm not against the idea of it being split up, or put in haxelib. I'd
just want to see a higher level of discipline when compared to other
libraries. Lacking a full test suite it is imperative that experimental
changes are not made to the core library. It can have too much of an
impact on existing 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: Standard library as haxelib

Nicolas Cannasse
In reply to this post by Michiel Crefcoeur
Michiel Crefcoeur a écrit :
> I think that every haxe user that's familiar with haxelib has asked
> him-/herself the question:
> "Why isn't the standard library (std) a haxelib?"
>
> Ofcourse, the answer would be that haxelib wasn't around when the
> standard library was first released.
>
> But now that we have haxelib, is there any reason not to move the
> standard library to haxelib?

One other reason is that you need the standard library installed in
order to compile haxelib, so there's chicken-and-egg issue occurring there.

I'm not in favor of splitting compiler and stdlib releases since this
would most likely result in a lot of things getting broken often, when a
new stdlib version is released which requires a particular compiler
feature of bugfix which is not yet available.

I consider that the current stdlib is quite stable, and although we are
planning big reorganization for next haXe major version, this would most
likely not require it to be release much more often than the compiler is
currently.

Do you have some examples of fixes/additions that you would like to get
released faster than the compiler ?

Nicolas


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

Re: Standard library as haxelib

Michiel Crefcoeur

Do you have some examples of fixes/additions that you would like to get released faster than the compiler ?

Nicolas


I think the main distribution would only need to contain implementations of the base (root) types. As a library, but one that comes pre-installed with haXe. All the other classes could be seperated in haxelibs. I don't have any concrete examples but in general, seperating code from the main distribution and going further, splitting them up into seperate libraries, patches and updates to these classes can take place more frequently.

Imagine a new target becomes available in the compiler. This means we can now compile haXe syntax to syntax / bytecode of another language. But since the compiler and the standard library are bundled, we can only effectively use this new compiler target once at least all types in the standard haXe library are updated to offer support. This holds back haXes growth since every new target can only get released once all standard classes are implemented and as the standard library grows, adding a new compiler target gets increasingly more work.

If the standard library would only consist of the base (root) types, only these would have to be updated in order to release the updated compiler.

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

Re: Standard library as haxelib

Cauê W.
well, I have a very concrete example of this:
I'm on the final tests for releasing an asc 'pseudo'-target. ASC is the format for server-side scripting with Flash Media Server. It's a pseudo target since its actually javascript, but has standard libraries very close to flash8, and it requires making some alterations on the std lib to make it work. I've been able to use it alongside with neko Socket ThreadRemotingServer, and I've implemented many libs that are similar to neko's: asc.io.File, etc.
Remoting is working just fine!

2010/4/22 Michiel Crefcoeur <[hidden email]>

Do you have some examples of fixes/additions that you would like to get released faster than the compiler ?

Nicolas


I think the main distribution would only need to contain implementations of the base (root) types. As a library, but one that comes pre-installed with haXe. All the other classes could be seperated in haxelibs. I don't have any concrete examples but in general, seperating code from the main distribution and going further, splitting them up into seperate libraries, patches and updates to these classes can take place more frequently.

Imagine a new target becomes available in the compiler. This means we can now compile haXe syntax to syntax / bytecode of another language. But since the compiler and the standard library are bundled, we can only effectively use this new compiler target once at least all types in the standard haXe library are updated to offer support. This holds back haXes growth since every new target can only get released once all standard classes are implemented and as the standard library grows, adding a new compiler target gets increasingly more work.

If the standard library would only consist of the base (root) types, only these would have to be updated in order to release the updated compiler.

--
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: Standard library as haxelib

Michiel Crefcoeur
In reply to this post by Michiel Crefcoeur
To complete my previous message:

All the classes that now make up the standard library could still be part of the main distribution, just in the form of haxelibs that can each be updated seperately:

haxe/std/ becomes haxe/lib/std/1,0/ that would only contain base types.

And (for example!):

haxe/lib/databases could contain all database related classes

Better yet:

haxe/lib/mysql
haxe/lib/sqlite

And, if you ask me, even better yet:

haxe/lib/mysql-cpp
haxe/lib/mysql-neko
haxe/lib/sqlite-cpp
haxe/lib/sqlite-neko

since this makes implementing classes for a new compiler target easier:

haxe/lib/sqlite-mynewtarget <- written by the developer of the new target
haxe/lib/mysql-mynewtarget <- written by some other developer

2010/4/22 Michiel Crefcoeur <[hidden email]>

Do you have some examples of fixes/additions that you would like to get released faster than the compiler ?

Nicolas


I think the main distribution would only need to contain implementations of the base (root) types. As a library, but one that comes pre-installed with haXe. All the other classes could be seperated in haxelibs. I don't have any concrete examples but in general, seperating code from the main distribution and going further, splitting them up into seperate libraries, patches and updates to these classes can take place more frequently.

Imagine a new target becomes available in the compiler. This means we can now compile haXe syntax to syntax / bytecode of another language. But since the compiler and the standard library are bundled, we can only effectively use this new compiler target once at least all types in the standard haXe library are updated to offer support. This holds back haXes growth since every new target can only get released once all standard classes are implemented and as the standard library grows, adding a new compiler target gets increasingly more work.

If the standard library would only consist of the base (root) types, only these would have to be updated in order to release the updated compiler.


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

Re: Standard library as haxelib

Michiel Crefcoeur
In reply to this post by Cauê W.
I've had exactly the same experience while building JScript.NET, Rhino and ASP/WSH/HTA pseudo-targets as you call it. I have these targets ready and working but I don't have the time for, nor intend to write all the standard classes for these targets.

2010/4/22 Cauê Waneck <[hidden email]>
well, I have a very concrete example of this:
I'm on the final tests for releasing an asc 'pseudo'-target. ASC is the format for server-side scripting with Flash Media Server. It's a pseudo target since its actually javascript, but has standard libraries very close to flash8, and it requires making some alterations on the std lib to make it work. I've been able to use it alongside with neko Socket ThreadRemotingServer, and I've implemented many libs that are similar to neko's: asc.io.File, etc.
Remoting is working just fine!

2010/4/22 Michiel Crefcoeur <[hidden email]>

Do you have some examples of fixes/additions that you would like to get released faster than the compiler ?

Nicolas


I think the main distribution would only need to contain implementations of the base (root) types. As a library, but one that comes pre-installed with haXe. All the other classes could be seperated in haxelibs. I don't have any concrete examples but in general, seperating code from the main distribution and going further, splitting them up into seperate libraries, patches and updates to these classes can take place more frequently.

Imagine a new target becomes available in the compiler. This means we can now compile haXe syntax to syntax / bytecode of another language. But since the compiler and the standard library are bundled, we can only effectively use this new compiler target once at least all types in the standard haXe library are updated to offer support. This holds back haXes growth since every new target can only get released once all standard classes are implemented and as the standard library grows, adding a new compiler target gets increasingly more work.

If the standard library would only consist of the base (root) types, only these would have to be updated in order to release the updated compiler.

--

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: Standard library as haxelib

edA-qa mort-ora-y
In reply to this post by Michiel Crefcoeur
Michiel Crefcoeur wrote:
> All the classes that now make up the standard library could still be
> part of the main distribution, just in the form of haxelibs that can
> each be updated seperately:

It sounds like a good branching/merging strategy would be more
appropriate here than haxelibs.  The core library should stay in one
place. There are a lot of compatibility issues and I think everybody
agrees the core libraries must be remain very stable.

This in my mind sounds like a good situation for branches and merging at
appropriate times. Using something like bzr, or git, this should be
straight forward and allow anybody to pickup the experimental backends
as they are being produced. Once proved to be stable they can be merged
into the main line.

--
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: Standard library as haxelib

Michiel Crefcoeur
In what way would it have a negative impact on the core library classes if they were haxelibs?

2010/4/23 edA-qa mort-ora-y <[hidden email]>
Michiel Crefcoeur wrote:
> All the classes that now make up the standard library could still be
> part of the main distribution, just in the form of haxelibs that can
> each be updated seperately:

It sounds like a good branching/merging strategy would be more
appropriate here than haxelibs.  The core library should stay in one
place. There are a lot of compatibility issues and I think everybody
agrees the core libraries must be remain very stable.

This in my mind sounds like a good situation for branches and merging at
appropriate times. Using something like bzr, or git, this should be
straight forward and allow anybody to pickup the experimental backends
as they are being produced. Once proved to be stable they can be merged
into the main line.

--
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: Standard library as haxelib

edA-qa mort-ora-y
Michiel Crefcoeur wrote:
> In what way would it have a negative impact on the core library classes
> if they were haxelibs?

Versioning. As haxe itself has new features, or alters in some way it's
backend there are other changes that need to be made to the standard
libraries. Similarly, as the stdlib changes it may take advantage of
newer features in haxe.

The difficulty becomes now that if you want a specific version of haxe
and its stdlib, that can be difficult using haxelib. Say I want to use
haxe 2.4, how would I go about getting the appropriate stdlib for that
version.  Now consider that somebody is already working on a new version
for a CVS only version of haxe. How do they get that into haxelib.

haxelib's versioning in my experience is quite limited, therefore you
can't adequately track dependencies between projects.

--
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: Standard library as haxelib

Michiel Crefcoeur
True, but this can be solved by extending the haxelib.xml spec.
Which is something that needs to be done anyway to make sure library developers can manage the haxe compiler versions that are supported.
I understand that we can't just move the std lib and be done with it, it needs some extra work to haxelib but these are all new features that are useful for libraries in general, for instance, extend the xml spec to include supported compiler targets and add some intelligence to haxelib.exe so it automatically sends the compiler version that's being used. And it should be possible to supply a -target argument so that it will check and download the library for the supplied target. This would allow us to write and distribute cross-target libraries more easy and make it more easy to distribute the work required for each target to other developers. This is the way we build our haxelibs and it works great, no more compiler directives: all target-specific code is in its own library. The only thing missing is an automated way of relating the compiler target to the correct libraries. So we do this through our own naming convention. If compiler targets would become part of the spec and the protocol, both haxelib and the compiler would "understand" which libraries to use/download.

This would be really easy to implement if the "depends" tags would have a target property.
Or something along that line.
This way, a library can have target-specific dependencies while the other way of doing cross-target classes is also still supported.


2010/4/23 edA-qa mort-ora-y <[hidden email]>
Michiel Crefcoeur wrote:
> In what way would it have a negative impact on the core library classes
> if they were haxelibs?

Versioning. As haxe itself has new features, or alters in some way it's
backend there are other changes that need to be made to the standard
libraries. Similarly, as the stdlib changes it may take advantage of
newer features in haxe.

The difficulty becomes now that if you want a specific version of haxe
and its stdlib, that can be difficult using haxelib. Say I want to use
haxe 2.4, how would I go about getting the appropriate stdlib for that
version.  Now consider that somebody is already working on a new version
for a CVS only version of haxe. How do they get that into haxelib.

haxelib's versioning in my experience is quite limited, therefore you
can't adequately track dependencies between projects.

--
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: Standard library as haxelib

edA-qa mort-ora-y
Michiel Crefcoeur wrote:
> great, no more compiler directives: all target-specific code is in its
> own library. The only thing missing is an automated way of relating the

The problem here of course is that if the standard library introduces a
new function then all those dispersed projects will be unusable with the
new haxe. In such a situation I've fear that those other standard
libraries can quickly grow obsolete or unusable.

I'm not speaking just in terms of technical challenges. With some
changes to haxelib I'm sure the dependencies can be solved. This is a
lot to do with people challenges. Say that Nicolas has a new version of
haxe but it requires a new stdlib function -- if one of those developers
isn't available, even temporarily, it would prevent release of that version.

So I would be in favour of technically splitting the stdlib into parts,
I don't like the idea of independent management of those parts. There
needs to be a strong coordinated effort to ensure all backends are
usuable for any released version of haxe.

--
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: Standard library as haxelib

Michiel Crefcoeur

I'm not speaking just in terms of technical challenges. With some
changes to haxelib I'm sure the dependencies can be solved. This is a
lot to do with people challenges. Say that Nicolas has a new version of
haxe but it requires a new stdlib function -- if one of those developers
isn't available, even temporarily, it would prevent release of that version. 

The same applies to the current situation. The only difference is: it's all part of the same big project. Currently, incomplete target support prevents release of a new version of the compiler. The situation that I propose is one where a new target can be released as soon as only the base types are implemented. Ofcourse, it would be up to the maintainers of the various libraries to make sure their library supports the new target but that's also the case right now for existing libraries! The difference is: library developers don't have to wait for the standard libraries compatibility to make their own libraries compatible. And the sub-libraries don't have to be maintained by different developers ofcourse. So it would still be possible to only release the new version of the compiler as soon as the "standard" classes are all up-to-date. It's just that it doesn't HAVE to be this way anymore. It's about choise and letting people have a new compiler target to work with that might not support all the "standard" classes from the beginning but at least they can use it for other purposes: for instance: write programs that don't use these classes or add compatibility for their own libraries.


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

Re: Standard library as haxelib

edA-qa mort-ora-y
Michiel Crefcoeur wrote:
> It's just that it doesn't HAVE to be this way anymore. It's about choise
> and letting people have a new compiler target to work with that might
> not support all the "standard" classes from the beginning but at least
> they can use it for other purposes: for instance: write programs that
> don't use these classes or add compatibility for their own libraries.

I don't think we're at odds here. I'm going to agree with most of this.
My major point is that I don't think haxelib is a suitable way to
achieve what you want. It has been my experience with other projects
that branches and merging are more suitable way to achieve this goal.

With things being branches there is always the understanding it is a
more key part to a project than just a library. Maintainers of branches
can merge new haxe changes in as they are able to, and as a branch
reaches some maturity it can be merged into the main haxe project. This
is an excellent way to let all developers work freely, but at the same
time ensure there is an official main version.

--
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: Standard library as haxelib

Justin Donaldson
I remember some talk about setting up different target variations for haXe.  One variation might be a "server" type target (such as php, cpp, neko) that has access to file i/o.  Another might be a "graphics" type target such as cpp/flash.

I'm not sure what Nicolas has in store for the next major revision of haXe, but perhaps some sort of implements-like arrangement can be made for language targets, the same way that classes implement different interfaces.  Maybe a target spec would have some sort of metadata for the compiler, like:

target java requires Haxe25 implements Std, Graphics, File, Network, (etc.)

The target would be specified by some new generic hxml command:
-target java

The compiler would then expect to find the corresponding target api code in a lib folder, rather than as conditionally compiled sections in the base classes.

Target developers could then specify that their target implements a few types of basic functionality, but doesn't implement others (perhaps not even the std library). It also could presumably specify a haxe version (or range of versions).

Nicolas, Hugh, and Franco could continue to maintain just the "batteries included" parts of the HaXe API, and then the rest of us could create and share partially formed one-off targets that serve special needs.

Best,
-Justin


On Fri, Apr 23, 2010 at 12:48 PM, edA-qa mort-ora-y <[hidden email]> wrote:
Michiel Crefcoeur wrote:
> It's just that it doesn't HAVE to be this way anymore. It's about choise
> and letting people have a new compiler target to work with that might
> not support all the "standard" classes from the beginning but at least
> they can use it for other purposes: for instance: write programs that
> don't use these classes or add compatibility for their own libraries.

I don't think we're at odds here. I'm going to agree with most of this.
My major point is that I don't think haxelib is a suitable way to
achieve what you want. It has been my experience with other projects
that branches and merging are more suitable way to achieve this goal.

With things being branches there is always the understanding it is a
more key part to a project than just a library. Maintainers of branches
can merge new haxe changes in as they are able to, and as a branch
reaches some maturity it can be merged into the main haxe project. This
is an excellent way to let all developers work freely, but at the same
time ensure there is an official main version.

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



--
Justin Donaldson
PhD Candidate, Informatics
Indiana University
http://www.scwn.net
aim: iujjd
twitter: jjdonald

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

Re: Standard library as haxelib

tong-2
In reply to this post by Nicolas Cannasse
On 04/22/2010 10:29 AM, Nicolas Cannasse wrote:

> Michiel Crefcoeur a écrit :
>> I think that every haxe user that's familiar with haxelib has asked
>> him-/herself the question:
>> "Why isn't the standard library (std) a haxelib?"
>>
>> Ofcourse, the answer would be that haxelib wasn't around when the
>> standard library was first released.
>>
>> But now that we have haxelib, is there any reason not to move the
>> standard library to haxelib?
>
> One other reason is that you need the standard library installed in
> order to compile haxelib, so there's chicken-and-egg issue occurring
> there.
>
> I'm not in favor of splitting compiler and stdlib releases since this
> would most likely result in a lot of things getting broken often, when
> a new stdlib version is released which requires a particular compiler
> feature of bugfix which is not yet available.
>
> I consider that the current stdlib is quite stable, and although we
> are planning big reorganization for next haXe major version, this
> would most likely not require it to be release much more often than
> the compiler is currently.
>
> Do you have some examples of fixes/additions that you would like to
> get released faster than the compiler ?
>
> Nicolas
>
>

...
a switch for the compiler to specify the path to the std to use would be
handy:
-std path/to/std

while we currently can simply replace the std folder/files ..
.. its a pain if you have several build targtes each using a different
version of a modified std lib.

/t

--
[) | 5 |<  † |2 3 3


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

Re: Standard library as haxelib

Franco Ponticelli

a switch for the compiler to specify the path to the std to use would be handy:
-std path/to/std

Why do you need that? As long as you use in your project the same file structure that exists in std, you can replace the files that you want. If you don't want to copy those files all around the projects make a lib of your modified std classes.

Franco

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

Re: Standard library as haxelib

tong-2
On 05/15/2010 04:47 PM, Franco Ponticelli wrote:

a switch for the compiler to specify the path to the std to use would be handy:
-std path/to/std

Why do you need that? As long as you use in your project the same file structure that exists in std, you can replace the files that you want. If you don't want to copy those files all around the projects make a lib of your modified std classes.

Franco

well. thats a possibility.

-- 
[) | 5 |< † |2 3 3 

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