Mergining *.io and *.filesystem

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

Mergining *.io and *.filesystem

Juan Delgado
Hi there,

Looking at the API there's:

http://haxe.org/api/neko/io
http://haxe.org/api/cpp/io
http://haxe.org/api/php/io

http://haxe.org/api/neko/filesystem
http://haxe.org/api/cpp/filesystem
http://haxe.org/api/php/filesystem

Is there a reason to keep them separated? Being haXe all about
crossplatform and having such a similar API, why is this not handled
internally via conditional compilation?

Is it something you guys (Nicolas, Hugh, Franco) are just not
interested in or you think it would be a nightmare to
implement/maintain? Or is this something people is meant to bypass
with the "using" keyword?

Anyway, I can give it a go myself in XAPI (btw, version 0.2 is on
haxelib now with some bug fixes, and nicer looking docs) but this
looks like something that might be nice in the std API.

Please let me know if I'm missing something,

Thanks,

Juan

--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

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

Re: Mergining *.io and *.filesystem

Heinz Hölzer-2
Instead of Merging them together, you can already create a pseudo
package to use all of them together:


let's take *.FileSystem as an Example
-----------------------------------------------
package sys;

typedef FileSystem = #if neko neko #elseif cpp cpp #elseif php php
#end.FileSystem;
-----------------------------------------------

now you can refer to sys.FileSystem without taking care of the target
and without remapping.

but this is only cross-plattform for methods that exists for all targets.

it would be great to hide non cross plattform (or expose cross
plattform) methods in some way. (like friendly types for instances)

********pseudocode***********

typedef FileSystemOrig = #if neko neko #elseif cpp cpp #elseif php php
#end.FileSystem;

typedef FileSystem extends FileSystemOrig but hides {
     hiddenfunction1;
}

or by exposing

typedef FileSystem extends FileSystemOrig privately but exposes{
      exposedfunction1;
}

*****************************

this would make cross-plattform development a lot easier. And it would
decrease the use of repeated conditional compilation instructions
(better readability and maintainability).







Am 21.02.2010 16:23, schrieb Juan Delgado:

> Hi there,
>
> Looking at the API there's:
>
> http://haxe.org/api/neko/io
> http://haxe.org/api/cpp/io
> http://haxe.org/api/php/io
>
> http://haxe.org/api/neko/filesystem
> http://haxe.org/api/cpp/filesystem
> http://haxe.org/api/php/filesystem
>
> Is there a reason to keep them separated? Being haXe all about
> crossplatform and having such a similar API, why is this not handled
> internally via conditional compilation?
>
> Is it something you guys (Nicolas, Hugh, Franco) are just not
> interested in or you think it would be a nightmare to
> implement/maintain? Or is this something people is meant to bypass
> with the "using" keyword?
>
> Anyway, I can give it a go myself in XAPI (btw, version 0.2 is on
> haxelib now with some bug fixes, and nicer looking docs) but this
> looks like something that might be nice in the std API.
>
> Please let me know if I'm missing something,
>
> Thanks,
>
> Juan
>
>    


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

Re: Mergining *.io and *.filesystem

tong-2
On Sun, 2010-02-21 at 16:58 +0100, Heinz Hölzer wrote:

> Instead of Merging them together, you can already create a pseudo
> package to use all of them together:
>
>
> let's take *.FileSystem as an Example
> -----------------------------------------------
> package sys;
>
> typedef FileSystem = #if neko neko #elseif cpp cpp #elseif php php
> #end.FileSystem;
> -----------------------------------------------
>
> now you can refer to sys.FileSystem without taking care of the target
> and without remapping.
>
> but this is only cross-plattform for methods that exists for all targets.


or you can use the 'remap' compiler flag,
since the three targets share the same API for file IO.
neko.FileSystem:php.FileSystem

--remap <package:target> : remap a package to another one



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


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

Re: Mergining *.io and *.filesystem

Justin Donaldson
I think this in the works for one of the upcoming releases:
http://haxe.org/com/features
(package changes)

-Justin

On Sun, Feb 21, 2010 at 11:43 AM, tong <[hidden email]> wrote:
On Sun, 2010-02-21 at 16:58 +0100, Heinz Hölzer wrote:
> Instead of Merging them together, you can already create a pseudo
> package to use all of them together:
>
>
> let's take *.FileSystem as an Example
> -----------------------------------------------
> package sys;
>
> typedef FileSystem = #if neko neko #elseif cpp cpp #elseif php php
> #end.FileSystem;
> -----------------------------------------------
>
> now you can refer to sys.FileSystem without taking care of the target
> and without remapping.
>
> but this is only cross-plattform for methods that exists for all targets.


or you can use the 'remap' compiler flag,
since the three targets share the same API for file IO.
neko.FileSystem:php.FileSystem

--remap <package:target> : remap a package to another one



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


--
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: Mergining *.io and *.filesystem

Juan Delgado
Ahh, nice to see it's been raised before.

Well, I think it definitely should be transparent for the user unless
there's a good reason against it. That means a unique API inside a
common package and then whatever implementation depending on the
target you are compiling to.

I wouldn't put all implementations on the same file, though. Let's say
there is a class:

* sys.File

Inside sys file I would use any of the tricks described above so it
ends up using the right implementation for the target platform. Those
files could be located in:

* sys.cpp.File
* sys.php.File
* sys.neko.File
* etc

Or something similar to prevent classes to grow huge. Also it should
make easier adding more targets in the future (as stated in the Wiki).
It would also allow extra platform-specific methods in case they are
needed, but it would be dead clear to the user that those are NOT
crossplatform. Similar to Systools, where everything in the main
package is crossplatform with OS specific packages:

http://code.google.com/p/neko-systools/source/browse/#svn/trunk/api/systools

Juan

On Sun, Feb 21, 2010 at 4:50 PM, Justin Donaldson <[hidden email]> wrote:

> I think this in the works for one of the upcoming releases:
> http://haxe.org/com/features
> (package changes)
>
> -Justin
>
> On Sun, Feb 21, 2010 at 11:43 AM, tong <[hidden email]> wrote:
>>
>> On Sun, 2010-02-21 at 16:58 +0100, Heinz Hölzer wrote:
>> > Instead of Merging them together, you can already create a pseudo
>> > package to use all of them together:
>> >
>> >
>> > let's take *.FileSystem as an Example
>> > -----------------------------------------------
>> > package sys;
>> >
>> > typedef FileSystem = #if neko neko #elseif cpp cpp #elseif php php
>> > #end.FileSystem;
>> > -----------------------------------------------
>> >
>> > now you can refer to sys.FileSystem without taking care of the target
>> > and without remapping.
>> >
>> > but this is only cross-plattform for methods that exists for all
>> > targets.
>>
>>
>> or you can use the 'remap' compiler flag,
>> since the three targets share the same API for file IO.
>> neko.FileSystem:php.FileSystem
>>
>> --remap <package:target> : remap a package to another one
>>
>>
>> 
>> --
>> [)   |   5   |<   †   |2   3   3
>>
>>
>> --
>> 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
>



--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

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

Re: Mergining *.io and *.filesystem

Juan Delgado
Hi again,

I've got this kind of working using typedefs as aliases as suggested
in the docs:

http://haxe.org/ref/type_advanced

The only problem I've found is a little inconsistency in php*, but
apart from that it seems to be ok.

If I'm correct, using typedefs shouldn't affect performance since they
are for the compiler only, right?

I'll commit this as soon as the php problem is fixed.

Cheers,

Juan

* http://code.google.com/p/haxe/issues/detail?id=85

On Sun, Feb 21, 2010 at 6:34 PM, Juan Delgado <[hidden email]> wrote:

> Ahh, nice to see it's been raised before.
>
> Well, I think it definitely should be transparent for the user unless
> there's a good reason against it. That means a unique API inside a
> common package and then whatever implementation depending on the
> target you are compiling to.
>
> I wouldn't put all implementations on the same file, though. Let's say
> there is a class:
>
> * sys.File
>
> Inside sys file I would use any of the tricks described above so it
> ends up using the right implementation for the target platform. Those
> files could be located in:
>
> * sys.cpp.File
> * sys.php.File
> * sys.neko.File
> * etc
>
> Or something similar to prevent classes to grow huge. Also it should
> make easier adding more targets in the future (as stated in the Wiki).
> It would also allow extra platform-specific methods in case they are
> needed, but it would be dead clear to the user that those are NOT
> crossplatform. Similar to Systools, where everything in the main
> package is crossplatform with OS specific packages:
>
> http://code.google.com/p/neko-systools/source/browse/#svn/trunk/api/systools
>
> Juan
>
> On Sun, Feb 21, 2010 at 4:50 PM, Justin Donaldson <[hidden email]> wrote:
>> I think this in the works for one of the upcoming releases:
>> http://haxe.org/com/features
>> (package changes)
>>
>> -Justin
>>
>> On Sun, Feb 21, 2010 at 11:43 AM, tong <[hidden email]> wrote:
>>>
>>> On Sun, 2010-02-21 at 16:58 +0100, Heinz Hölzer wrote:
>>> > Instead of Merging them together, you can already create a pseudo
>>> > package to use all of them together:
>>> >
>>> >
>>> > let's take *.FileSystem as an Example
>>> > -----------------------------------------------
>>> > package sys;
>>> >
>>> > typedef FileSystem = #if neko neko #elseif cpp cpp #elseif php php
>>> > #end.FileSystem;
>>> > -----------------------------------------------
>>> >
>>> > now you can refer to sys.FileSystem without taking care of the target
>>> > and without remapping.
>>> >
>>> > but this is only cross-plattform for methods that exists for all
>>> > targets.
>>>
>>>
>>> or you can use the 'remap' compiler flag,
>>> since the three targets share the same API for file IO.
>>> neko.FileSystem:php.FileSystem
>>>
>>> --remap <package:target> : remap a package to another one
>>>
>>>
>>> 
>>> --
>>> [)   |   5   |<   †   |2   3   3
>>>
>>>
>>> --
>>> 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
>>
>
>
>
> --
> Juan Delgado - Zárate
> http://zarate.tv
> http://blog.zarate.tv
>



--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

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

Re: Mergining *.io and *.filesystem

Benjamin Dasnois
Typedefs being used only at compile-time doesn't mean that they won't
affect performances... In fact, your values may well be typed as
Dynamics so it will bring down performances maybe... Someone wrote an
article about that (I'd bet it's certainly Nicolas or Franco).

Regards,

On Tue, Feb 23, 2010 at 11:36 PM, Juan Delgado <[hidden email]> wrote:

> Hi again,
>
> I've got this kind of working using typedefs as aliases as suggested
> in the docs:
>
> http://haxe.org/ref/type_advanced
>
> The only problem I've found is a little inconsistency in php*, but
> apart from that it seems to be ok.
>
> If I'm correct, using typedefs shouldn't affect performance since they
> are for the compiler only, right?
>
> I'll commit this as soon as the php problem is fixed.
>
> Cheers,
>
> Juan
>
> * http://code.google.com/p/haxe/issues/detail?id=85
>
> On Sun, Feb 21, 2010 at 6:34 PM, Juan Delgado <[hidden email]> wrote:
>> Ahh, nice to see it's been raised before.
>>
>> Well, I think it definitely should be transparent for the user unless
>> there's a good reason against it. That means a unique API inside a
>> common package and then whatever implementation depending on the
>> target you are compiling to.
>>
>> I wouldn't put all implementations on the same file, though. Let's say
>> there is a class:
>>
>> * sys.File
>>
>> Inside sys file I would use any of the tricks described above so it
>> ends up using the right implementation for the target platform. Those
>> files could be located in:
>>
>> * sys.cpp.File
>> * sys.php.File
>> * sys.neko.File
>> * etc
>>
>> Or something similar to prevent classes to grow huge. Also it should
>> make easier adding more targets in the future (as stated in the Wiki).
>> It would also allow extra platform-specific methods in case they are
>> needed, but it would be dead clear to the user that those are NOT
>> crossplatform. Similar to Systools, where everything in the main
>> package is crossplatform with OS specific packages:
>>
>> http://code.google.com/p/neko-systools/source/browse/#svn/trunk/api/systools
>>
>> Juan
>>
>> On Sun, Feb 21, 2010 at 4:50 PM, Justin Donaldson <[hidden email]> wrote:
>>> I think this in the works for one of the upcoming releases:
>>> http://haxe.org/com/features
>>> (package changes)
>>>
>>> -Justin
>>>
>>> On Sun, Feb 21, 2010 at 11:43 AM, tong <[hidden email]> wrote:
>>>>
>>>> On Sun, 2010-02-21 at 16:58 +0100, Heinz Hölzer wrote:
>>>> > Instead of Merging them together, you can already create a pseudo
>>>> > package to use all of them together:
>>>> >
>>>> >
>>>> > let's take *.FileSystem as an Example
>>>> > -----------------------------------------------
>>>> > package sys;
>>>> >
>>>> > typedef FileSystem = #if neko neko #elseif cpp cpp #elseif php php
>>>> > #end.FileSystem;
>>>> > -----------------------------------------------
>>>> >
>>>> > now you can refer to sys.FileSystem without taking care of the target
>>>> > and without remapping.
>>>> >
>>>> > but this is only cross-plattform for methods that exists for all
>>>> > targets.
>>>>
>>>>
>>>> or you can use the 'remap' compiler flag,
>>>> since the three targets share the same API for file IO.
>>>> neko.FileSystem:php.FileSystem
>>>>
>>>> --remap <package:target> : remap a package to another one
>>>>
>>>>
>>>> 
>>>> --
>>>> [)   |   5   |<   †   |2   3   3
>>>>
>>>>
>>>> --
>>>> 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
>>>
>>
>>
>>
>> --
>> Juan Delgado - Zárate
>> http://zarate.tv
>> http://blog.zarate.tv
>>
>
>
>
> --
> Juan Delgado - Zárate
> http://zarate.tv
> http://blog.zarate.tv
>
> --
> 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: Mergining *.io and *.filesystem

Heinz Hölzer-2
I think this differs depending on the type of the typedef

for example, this code
----------------------------------------
class Point {
     var x : Int;
     public function new () {}
}

typedef TPoint = Point;

class Main {
   static function main()
   {
       var a : TPoint = new TPoint();
   }
}
----------------------------------------

compiles to this as3 code

----------------------------------------
public class Main {
         static public function main() : void {
             var a : Point = new Point();
         }
}
----------------------------------------

so a typedef, used as an alias for another class, is not typed as Dynamic.



Am 24.02.2010 00:25, schrieb Benjamin Dasnois:

> Typedefs being used only at compile-time doesn't mean that they won't
> affect performances... In fact, your values may well be typed as
> Dynamics so it will bring down performances maybe... Someone wrote an
> article about that (I'd bet it's certainly Nicolas or Franco).
>
> Regards,
>
> On Tue, Feb 23, 2010 at 11:36 PM, Juan Delgado<[hidden email]>  wrote:
>    
>> Hi again,
>>
>> I've got this kind of working using typedefs as aliases as suggested
>> in the docs:
>>
>> http://haxe.org/ref/type_advanced
>>
>> The only problem I've found is a little inconsistency in php*, but
>> apart from that it seems to be ok.
>>
>> If I'm correct, using typedefs shouldn't affect performance since they
>> are for the compiler only, right?
>>
>> I'll commit this as soon as the php problem is fixed.
>>
>> Cheers,
>>
>> Juan
>>
>> * http://code.google.com/p/haxe/issues/detail?id=85
>>
>> On Sun, Feb 21, 2010 at 6:34 PM, Juan Delgado<[hidden email]>  wrote:
>>      
>>> Ahh, nice to see it's been raised before.
>>>
>>> Well, I think it definitely should be transparent for the user unless
>>> there's a good reason against it. That means a unique API inside a
>>> common package and then whatever implementation depending on the
>>> target you are compiling to.
>>>
>>> I wouldn't put all implementations on the same file, though. Let's say
>>> there is a class:
>>>
>>> * sys.File
>>>
>>> Inside sys file I would use any of the tricks described above so it
>>> ends up using the right implementation for the target platform. Those
>>> files could be located in:
>>>
>>> * sys.cpp.File
>>> * sys.php.File
>>> * sys.neko.File
>>> * etc
>>>
>>> Or something similar to prevent classes to grow huge. Also it should
>>> make easier adding more targets in the future (as stated in the Wiki).
>>> It would also allow extra platform-specific methods in case they are
>>> needed, but it would be dead clear to the user that those are NOT
>>> crossplatform. Similar to Systools, where everything in the main
>>> package is crossplatform with OS specific packages:
>>>
>>> http://code.google.com/p/neko-systools/source/browse/#svn/trunk/api/systools
>>>
>>> Juan
>>>
>>> On Sun, Feb 21, 2010 at 4:50 PM, Justin Donaldson<[hidden email]>  wrote:
>>>        
>>>> I think this in the works for one of the upcoming releases:
>>>> http://haxe.org/com/features
>>>> (package changes)
>>>>
>>>> -Justin
>>>>
>>>> On Sun, Feb 21, 2010 at 11:43 AM, tong<[hidden email]>  wrote:
>>>>          
>>>>> On Sun, 2010-02-21 at 16:58 +0100, Heinz Hölzer wrote:
>>>>>            
>>>>>> Instead of Merging them together, you can already create a pseudo
>>>>>> package to use all of them together:
>>>>>>
>>>>>>
>>>>>> let's take *.FileSystem as an Example
>>>>>> -----------------------------------------------
>>>>>> package sys;
>>>>>>
>>>>>> typedef FileSystem = #if neko neko #elseif cpp cpp #elseif php php
>>>>>> #end.FileSystem;
>>>>>> -----------------------------------------------
>>>>>>
>>>>>> now you can refer to sys.FileSystem without taking care of the target
>>>>>> and without remapping.
>>>>>>
>>>>>> but this is only cross-plattform for methods that exists for all
>>>>>> targets.
>>>>>>              
>>>>>
>>>>> or you can use the 'remap' compiler flag,
>>>>> since the three targets share the same API for file IO.
>>>>> neko.FileSystem:php.FileSystem
>>>>>
>>>>> --remap<package:target>  : remap a package to another one
>>>>>
>>>>>
>>>>> 
>>>>> --
>>>>> [)   |   5   |<     †   |2   3   3
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>
>>>>          
>>>
>>>
>>> --
>>> Juan Delgado - Zárate
>>> http://zarate.tv
>>> http://blog.zarate.tv
>>>
>>>        
>>
>>
>> --
>> Juan Delgado - Zárate
>> http://zarate.tv
>> http://blog.zarate.tv
>>
>> --
>> 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: Mergining *.io and *.filesystem

Benjamin Dasnois
Yes, that absolutely makes sense. :) I have to admit it's quite late
there (so is it in your country ;)) and my mind was both here and
somewhere else.

2010/2/24 Heinz Hölzer <[hidden email]>:

> I think this differs depending on the type of the typedef
>
> for example, this code
> ----------------------------------------
> class Point {
>    var x : Int;
>    public function new () {}
> }
>
> typedef TPoint = Point;
>
> class Main {
>  static function main()
>  {
>      var a : TPoint = new TPoint();
>  }
> }
> ----------------------------------------
>
> compiles to this as3 code
>
> ----------------------------------------
> public class Main {
>        static public function main() : void {
>            var a : Point = new Point();
>        }
> }
> ----------------------------------------
>
> so a typedef, used as an alias for another class, is not typed as Dynamic.
>
>
>
> Am 24.02.2010 00:25, schrieb Benjamin Dasnois:
>>
>> Typedefs being used only at compile-time doesn't mean that they won't
>> affect performances... In fact, your values may well be typed as
>> Dynamics so it will bring down performances maybe... Someone wrote an
>> article about that (I'd bet it's certainly Nicolas or Franco).
>>
>> Regards,
>>
>> On Tue, Feb 23, 2010 at 11:36 PM, Juan Delgado<[hidden email]>  wrote:
>>
>>>
>>> Hi again,
>>>
>>> I've got this kind of working using typedefs as aliases as suggested
>>> in the docs:
>>>
>>> http://haxe.org/ref/type_advanced
>>>
>>> The only problem I've found is a little inconsistency in php*, but
>>> apart from that it seems to be ok.
>>>
>>> If I'm correct, using typedefs shouldn't affect performance since they
>>> are for the compiler only, right?
>>>
>>> I'll commit this as soon as the php problem is fixed.
>>>
>>> Cheers,
>>>
>>> Juan
>>>
>>> * http://code.google.com/p/haxe/issues/detail?id=85
>>>
>>> On Sun, Feb 21, 2010 at 6:34 PM, Juan Delgado<[hidden email]>  wrote:
>>>
>>>>
>>>> Ahh, nice to see it's been raised before.
>>>>
>>>> Well, I think it definitely should be transparent for the user unless
>>>> there's a good reason against it. That means a unique API inside a
>>>> common package and then whatever implementation depending on the
>>>> target you are compiling to.
>>>>
>>>> I wouldn't put all implementations on the same file, though. Let's say
>>>> there is a class:
>>>>
>>>> * sys.File
>>>>
>>>> Inside sys file I would use any of the tricks described above so it
>>>> ends up using the right implementation for the target platform. Those
>>>> files could be located in:
>>>>
>>>> * sys.cpp.File
>>>> * sys.php.File
>>>> * sys.neko.File
>>>> * etc
>>>>
>>>> Or something similar to prevent classes to grow huge. Also it should
>>>> make easier adding more targets in the future (as stated in the Wiki).
>>>> It would also allow extra platform-specific methods in case they are
>>>> needed, but it would be dead clear to the user that those are NOT
>>>> crossplatform. Similar to Systools, where everything in the main
>>>> package is crossplatform with OS specific packages:
>>>>
>>>>
>>>> http://code.google.com/p/neko-systools/source/browse/#svn/trunk/api/systools
>>>>
>>>> Juan
>>>>
>>>> On Sun, Feb 21, 2010 at 4:50 PM, Justin Donaldson<[hidden email]>
>>>>  wrote:
>>>>
>>>>>
>>>>> I think this in the works for one of the upcoming releases:
>>>>> http://haxe.org/com/features
>>>>> (package changes)
>>>>>
>>>>> -Justin
>>>>>
>>>>> On Sun, Feb 21, 2010 at 11:43 AM, tong<[hidden email]>  wrote:
>>>>>
>>>>>>
>>>>>> On Sun, 2010-02-21 at 16:58 +0100, Heinz Hölzer wrote:
>>>>>>
>>>>>>>
>>>>>>> Instead of Merging them together, you can already create a pseudo
>>>>>>> package to use all of them together:
>>>>>>>
>>>>>>>
>>>>>>> let's take *.FileSystem as an Example
>>>>>>> -----------------------------------------------
>>>>>>> package sys;
>>>>>>>
>>>>>>> typedef FileSystem = #if neko neko #elseif cpp cpp #elseif php php
>>>>>>> #end.FileSystem;
>>>>>>> -----------------------------------------------
>>>>>>>
>>>>>>> now you can refer to sys.FileSystem without taking care of the target
>>>>>>> and without remapping.
>>>>>>>
>>>>>>> but this is only cross-plattform for methods that exists for all
>>>>>>> targets.
>>>>>>>
>>>>>>
>>>>>> or you can use the 'remap' compiler flag,
>>>>>> since the three targets share the same API for file IO.
>>>>>> neko.FileSystem:php.FileSystem
>>>>>>
>>>>>> --remap<package:target>  : remap a package to another one
>>>>>>
>>>>>>
>>>>>> 
>>>>>> --
>>>>>> [)   |   5   |<     †   |2   3   3
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Juan Delgado - Zárate
>>>> http://zarate.tv
>>>> http://blog.zarate.tv
>>>>
>>>>
>>>
>>>
>>> --
>>> Juan Delgado - Zárate
>>> http://zarate.tv
>>> http://blog.zarate.tv
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>>
>>
>>
>>
>
>
> --
> 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: Mergining *.io and *.filesystem

Juan Delgado
Hi guys,

This is now in GitHub and done via conditional compilation and aliases
as said before. Will be part of next release of XAPI.

Thanks all for the help : )

Juan

On Tue, Feb 23, 2010 at 11:52 PM, Benjamin Dasnois
<[hidden email]> wrote:

> Yes, that absolutely makes sense. :) I have to admit it's quite late
> there (so is it in your country ;)) and my mind was both here and
> somewhere else.
>
> 2010/2/24 Heinz Hölzer <[hidden email]>:
>> I think this differs depending on the type of the typedef
>>
>> for example, this code
>> ----------------------------------------
>> class Point {
>>    var x : Int;
>>    public function new () {}
>> }
>>
>> typedef TPoint = Point;
>>
>> class Main {
>>  static function main()
>>  {
>>      var a : TPoint = new TPoint();
>>  }
>> }
>> ----------------------------------------
>>
>> compiles to this as3 code
>>
>> ----------------------------------------
>> public class Main {
>>        static public function main() : void {
>>            var a : Point = new Point();
>>        }
>> }
>> ----------------------------------------
>>
>> so a typedef, used as an alias for another class, is not typed as Dynamic.
>>
>>
>>
>> Am 24.02.2010 00:25, schrieb Benjamin Dasnois:
>>>
>>> Typedefs being used only at compile-time doesn't mean that they won't
>>> affect performances... In fact, your values may well be typed as
>>> Dynamics so it will bring down performances maybe... Someone wrote an
>>> article about that (I'd bet it's certainly Nicolas or Franco).
>>>
>>> Regards,
>>>
>>> On Tue, Feb 23, 2010 at 11:36 PM, Juan Delgado<[hidden email]>  wrote:
>>>
>>>>
>>>> Hi again,
>>>>
>>>> I've got this kind of working using typedefs as aliases as suggested
>>>> in the docs:
>>>>
>>>> http://haxe.org/ref/type_advanced
>>>>
>>>> The only problem I've found is a little inconsistency in php*, but
>>>> apart from that it seems to be ok.
>>>>
>>>> If I'm correct, using typedefs shouldn't affect performance since they
>>>> are for the compiler only, right?
>>>>
>>>> I'll commit this as soon as the php problem is fixed.
>>>>
>>>> Cheers,
>>>>
>>>> Juan
>>>>
>>>> * http://code.google.com/p/haxe/issues/detail?id=85
>>>>
>>>> On Sun, Feb 21, 2010 at 6:34 PM, Juan Delgado<[hidden email]>  wrote:
>>>>
>>>>>
>>>>> Ahh, nice to see it's been raised before.
>>>>>
>>>>> Well, I think it definitely should be transparent for the user unless
>>>>> there's a good reason against it. That means a unique API inside a
>>>>> common package and then whatever implementation depending on the
>>>>> target you are compiling to.
>>>>>
>>>>> I wouldn't put all implementations on the same file, though. Let's say
>>>>> there is a class:
>>>>>
>>>>> * sys.File
>>>>>
>>>>> Inside sys file I would use any of the tricks described above so it
>>>>> ends up using the right implementation for the target platform. Those
>>>>> files could be located in:
>>>>>
>>>>> * sys.cpp.File
>>>>> * sys.php.File
>>>>> * sys.neko.File
>>>>> * etc
>>>>>
>>>>> Or something similar to prevent classes to grow huge. Also it should
>>>>> make easier adding more targets in the future (as stated in the Wiki).
>>>>> It would also allow extra platform-specific methods in case they are
>>>>> needed, but it would be dead clear to the user that those are NOT
>>>>> crossplatform. Similar to Systools, where everything in the main
>>>>> package is crossplatform with OS specific packages:
>>>>>
>>>>>
>>>>> http://code.google.com/p/neko-systools/source/browse/#svn/trunk/api/systools
>>>>>
>>>>> Juan
>>>>>
>>>>> On Sun, Feb 21, 2010 at 4:50 PM, Justin Donaldson<[hidden email]>
>>>>>  wrote:
>>>>>
>>>>>>
>>>>>> I think this in the works for one of the upcoming releases:
>>>>>> http://haxe.org/com/features
>>>>>> (package changes)
>>>>>>
>>>>>> -Justin
>>>>>>
>>>>>> On Sun, Feb 21, 2010 at 11:43 AM, tong<[hidden email]>  wrote:
>>>>>>
>>>>>>>
>>>>>>> On Sun, 2010-02-21 at 16:58 +0100, Heinz Hölzer wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Instead of Merging them together, you can already create a pseudo
>>>>>>>> package to use all of them together:
>>>>>>>>
>>>>>>>>
>>>>>>>> let's take *.FileSystem as an Example
>>>>>>>> -----------------------------------------------
>>>>>>>> package sys;
>>>>>>>>
>>>>>>>> typedef FileSystem = #if neko neko #elseif cpp cpp #elseif php php
>>>>>>>> #end.FileSystem;
>>>>>>>> -----------------------------------------------
>>>>>>>>
>>>>>>>> now you can refer to sys.FileSystem without taking care of the target
>>>>>>>> and without remapping.
>>>>>>>>
>>>>>>>> but this is only cross-plattform for methods that exists for all
>>>>>>>> targets.
>>>>>>>>
>>>>>>>
>>>>>>> or you can use the 'remap' compiler flag,
>>>>>>> since the three targets share the same API for file IO.
>>>>>>> neko.FileSystem:php.FileSystem
>>>>>>>
>>>>>>> --remap<package:target>  : remap a package to another one
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>>> --
>>>>>>> [)   |   5   |<     †   |2   3   3
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Juan Delgado - Zárate
>>>>> http://zarate.tv
>>>>> http://blog.zarate.tv
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Juan Delgado - Zárate
>>>> http://zarate.tv
>>>> http://blog.zarate.tv
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> 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
>



--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv

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