Target Neutral Standard Library, Long Term Adaption

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

Target Neutral Standard Library, Long Term Adaption

Tyler MacLeod-2
Hi All,

I'm wondering what the general feeling and thoughts are on creating a
new Standard Library that would be target neutral?

Now that we have the @:core_api metatag, a new Standard Library could be
built. Writing the library based on a solid interface that shows the
best of what haXe has to offer without focusing on the individual target
implementation. Also, being able to use external libraries without
having to remember to add "--remap neko:cpp" would be nice.

The API could be developed concurrently with haXe 2.x, where one could
choice to use either one.  Then depending on it's development and
acceptance, I could see the following migration plan.

- 3.0 release: Compiler issues a warning when using the original library
- 4.0 release: Requires a compiler flag to access the original library
- 5.0 release: Remove access to the original library (should be plenty
of time for the migration by then, or you could always compile with an
older compiler)

haXeLib projects may behave differently, such as no warnings are issued
when using one, and adding a parameter to the lib config to say it uses
the original library.

Some caveats:

- I don't agree with design by committee as a principle. The API should
have the community involved in creating the goals and values for the
API, but should be designed by a few (3 or 5) people. This is of course,
just for the interface of the core api. The implementations for both
shared and target specific can and probably should be contributed by all
who which to help out.

- Obviously there are some functionality that are not available in all
targets, so there would still need to be a way to distinguish this, and
add errors like "haxe.db not available for the javascript target".
     - One thing that might be nice is to generalize these somewhat, if
possible. Such as saying target support one or more of web app (in
browser based i.e. js and flash), server side, command line, desktop
app, etc.
    - If done, the we can add the ability to libs so that they can add
these to different targets (neash like libraries).

- It might be best to avoid going too far with this, and avoid overly
complex or unnecessary items in the Std like certain "Enterprise"
languages out there. Then again, since the library is being carried
around like those languages, it wouldn't be that big of a problem.

That's more then enough to hopefully start a conversation at least.

-Tyler

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

Re: Target Neutral Standard Library, Long Term Adaption

Nicolas Cannasse
Le 14/05/2011 03:57, Tyler MacLeod a écrit :
> Hi All,
>
> I'm wondering what the general feeling and thoughts are on creating a
> new Standard Library that would be target neutral?

The current standard library (root classes + haxe package) IS target
neutral and perfectly cross platform. So my question would be : what
exactly do you want to add or modify that would be target neutral ?

For haXe 3.0 we are planning for instance to move all systems API
(sockets, file manipulation, etc) into a new toplevel "sys" package that
would be accessible for targets such as Neko,PHP,C++ (and C#/Java or
course).

People have been working on several efforts to have a crossplatform
graphics API. Most of the work so far is based on a port of the Flash
API (NME, Jeash, etc.) but it's quite hard to cover all the API. Maybe
having something less complex (such as Flixel) running fully
crossplatform could be a first goal, more easy to reach.

Best,
Nicolas

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

Re: Target Neutral Standard Library, Long Term Adaption

Tarwin Stroh-Spijer
On the Flixel case, I think I almost convinced Adam Saltsman (the guy who made Flixel) to try porting it himself to haxe and support that as the first port of call for both Flash and iPhone. He was going to look into it but I think he got busy with other things. If we do create a cross-platform one I have a feeling Flixel community would be very much behind it and we'd get a lot more devs on board!


Tarwin Stroh-Spijer
_______________________

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


On Sat, May 14, 2011 at 7:20 PM, Nicolas Cannasse <[hidden email]> wrote:
Le 14/05/2011 03:57, Tyler MacLeod a écrit :

Hi All,

I'm wondering what the general feeling and thoughts are on creating a
new Standard Library that would be target neutral?

The current standard library (root classes + haxe package) IS target neutral and perfectly cross platform. So my question would be : what exactly do you want to add or modify that would be target neutral ?

For haXe 3.0 we are planning for instance to move all systems API (sockets, file manipulation, etc) into a new toplevel "sys" package that would be accessible for targets such as Neko,PHP,C++ (and C#/Java or course).

People have been working on several efforts to have a crossplatform graphics API. Most of the work so far is based on a port of the Flash API (NME, Jeash, etc.) but it's quite hard to cover all the API. Maybe having something less complex (such as Flixel) running fully crossplatform could be a first goal, more easy to reach.

Best,
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: Target Neutral Standard Library, Long Term Adaption

Tyler MacLeod-2
In reply to this post by Nicolas Cannasse
On 14/05/2011 6:20 AM, Nicolas Cannasse wrote:

> Le 14/05/2011 03:57, Tyler MacLeod a écrit :
>> Hi All,
>>
>> I'm wondering what the general feeling and thoughts are on creating a
>> new Standard Library that would be target neutral?
>
> The current standard library (root classes + haxe package) IS target
> neutral and perfectly cross platform. So my question would be : what
> exactly do you want to add or modify that would be target neutral ?
>
> For haXe 3.0 we are planning for instance to move all systems API
> (sockets, file manipulation, etc) into a new toplevel "sys" package
> that would be accessible for targets such as Neko,PHP,C++ (and C#/Java
> or course).
>
Yes, this is the majority of the effort I'd like to see. To have it feel
more like I'm using haXe's API, rather then <insert target here>'s API.

With this toplevel package, would libraries be able to add these to
existing targets? For Example, An AIR library or Node.js library to
allow code written using the sys to be used by flash and js targets as well.

> People have been working on several efforts to have a crossplatform
> graphics API. Most of the work so far is based on a port of the Flash
> API (NME, Jeash, etc.) but it's quite hard to cover all the API. Maybe
> having something less complex (such as Flixel) running fully
> crossplatform could be a first goal, more easy to reach.
>
Also something I'd like to see.
> Best,
> Nicolas
>

-Tyler

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

Re: Target Neutral Standard Library, Long Term Adaption

Joshua Harlan Lifton
In reply to this post by Tarwin Stroh-Spijer
Seems there's already been a partial port of Flixel to haXe:

http://flixel.org/forums/index.php?topic=2549.0

Josh

On Sat, May 14, 2011 at 5:44 AM, Tarwin Stroh-Spijer
<[hidden email]> wrote:

> On the Flixel case, I think I almost convinced Adam Saltsman (the guy who
> made Flixel) to try porting it himself to haxe and support that as the first
> port of call for both Flash and iPhone. He was going to look into it but I
> think he got busy with other things. If we do create a cross-platform one I
> have a feeling Flixel community would be very much behind it and we'd get a
> lot more devs on board!
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: +61 3 8060 5321
> _______________________
>
>
> On Sat, May 14, 2011 at 7:20 PM, Nicolas Cannasse
> <[hidden email]> wrote:
>>
>> Le 14/05/2011 03:57, Tyler MacLeod a écrit :
>>>
>>> Hi All,
>>>
>>> I'm wondering what the general feeling and thoughts are on creating a
>>> new Standard Library that would be target neutral?
>>
>> The current standard library (root classes + haxe package) IS target
>> neutral and perfectly cross platform. So my question would be : what exactly
>> do you want to add or modify that would be target neutral ?
>>
>> For haXe 3.0 we are planning for instance to move all systems API
>> (sockets, file manipulation, etc) into a new toplevel "sys" package that
>> would be accessible for targets such as Neko,PHP,C++ (and C#/Java or
>> course).
>>
>> People have been working on several efforts to have a crossplatform
>> graphics API. Most of the work so far is based on a port of the Flash API
>> (NME, Jeash, etc.) but it's quite hard to cover all the API. Maybe having
>> something less complex (such as Flixel) running fully crossplatform could be
>> a first goal, more easy to reach.
>>
>> Best,
>> 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: Target Neutral Standard Library, Long Term Adaption

Tony Polinelli
In reply to this post by Tyler MacLeod-2


On Sat, May 14, 2011 at 10:20 PM, Tyler MacLeod <[hidden email]> wrote:
On 14/05/2011 6:20 AM, Nicolas Cannasse wrote:
Le 14/05/2011 03:57, Tyler MacLeod a écrit :
Hi All,

I'm wondering what the general feeling and thoughts are on creating a
new Standard Library that would be target neutral?

The current standard library (root classes + haxe package) IS target neutral and perfectly cross platform. So my question would be : what exactly do you want to add or modify that would be target neutral ?

For haXe 3.0 we are planning for instance to move all systems API (sockets, file manipulation, etc) into a new toplevel "sys" package that would be accessible for targets such as Neko,PHP,C++ (and C#/Java or course).

Yes, this is the majority of the effort I'd like to see. To have it feel more like I'm using haXe's API, rather then <insert target here>'s API.

With this toplevel package, would libraries be able to add these to existing targets? For Example, An AIR library or Node.js library to allow code written using the sys to be used by flash and js targets as well.

to change the standard lib (allow js to target server - nodejs- for instance) you might just need to have the file.hx in your classpth - with modifications. That would be the esiest way to modify te std lib, before changes becoming standard (released with haxe) is this what you mean?
 

People have been working on several efforts to have a crossplatform graphics API. Most of the work so far is based on a port of the Flash API (NME, Jeash, etc.) but it's quite hard to cover all the API. Maybe having something less complex (such as Flixel) running fully crossplatform could be a first goal, more easy to reach.

Also something I'd like to see.
Best,
Nicolas


-Tyler


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



--
Tony Polinelli
http://touchmypixel.com

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

Re: Target Neutral Standard Library, Long Term Adaption

Dion Whitehead Amago
> to change the standard lib (allow js to target server - nodejs- for
> instance) you might just need to have the file.hx in your classpth - with
> modifications. That would be the esiest way to modify te std lib, before
> changes becoming standard (released with haxe) is this what you mean?
>

The one problem with that solution is that macros don't work with
node.js, since macros use neko but find a node.js specific class
instead.  I've had to directly merge the node.js classes with the std
lib and add the appropriate compiler switches to get macros working
with node.js.

Dion

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