typedef alternative?

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

typedef alternative?

singmajesty
When I created libraries in Actionscript 3, I would sometimes create  
"internal" namespaces to communicate between members of my library, but to  
keep the public namespace clear for code completion.

In Haxe, I have used typedefs to emulate this functionality. However, I  
have recently learned that using typedefs like namespaces has a large  
performance hit in HXCPP. Is there an alternative I can use to achieve the  
same principle of namespacing?

For example, Actuate uses a jQuery-style syntax to provide code completion  
for all of its properties. When a user begins to chain properties, they  
should see valid options, like "delay" and "onComplete", not internal  
properties like "duration", "properties" or "move".

I suppose I can create a "dummy" object with only the methods I intend to  
forward. Are there other approaches?

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

Re: typedef alternative?

Gamehaxe
I simply use a prefix, eg:

  public var nmeHandle:Dynamic;

You can use "nme*" variables if you know what you are doing, if you don't  
then just leave them alone.
You can make your code harder to read, harder to write and slower buy why?
You could perhaps use the prefix "internal" to make it a bit more explicit.

Hugh



> When I created libraries in Actionscript 3, I would sometimes create  
> "internal" namespaces to communicate between members of my library, but  
> to keep the public namespace clear for code completion.
>
> In Haxe, I have used typedefs to emulate this functionality. However, I  
> have recently learned that using typedefs like namespaces has a large  
> performance hit in HXCPP. Is there an alternative I can use to achieve  
> the same principle of namespacing?
>
> For example, Actuate uses a jQuery-style syntax to provide code  
> completion for all of its properties. When a user begins to chain  
> properties, they should see valid options, like "delay" and  
> "onComplete", not internal properties like "duration", "properties" or  
> "move".
>
> I suppose I can create a "dummy" object with only the methods I intend  
> to forward. Are there other approaches?

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

Re: typedef alternative?

Pimm Hogeling
2011/8/21 Gamehaxe <[hidden email]>
You can make your code harder to read, harder to write and slower buy why?
Because Joshua is writing libraries.

A developer calling a method he isn't supposed to - I quote - "often results in broken trains of thought, wasted time, and lost work. This is called user error, but it isn’t. It is programmer or designer error. When we blame the user, we teach them that technology is perfect and that the errors are their own. Because technology is hard to use, we are teaching a generation to be afraid of technology."

This is a quote by Jono Xia about interfaces. I feel this applies to APIs as well.

If you have the choice, write a library that's hard to misuse and puts a smile on the user's face from the start; rather than a library that requires hours of source code reading and sweating before it can be used without stack overflows and explosions.

I personally feel merely using prefixes could go either way, depending on the context and the prefix itself.

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

Re: typedef alternative?

Gamehaxe
Well it seems you can choose to restrict access to "none",
"annoying and slow" or "mysterious name".  Least of 3 evils.

The main problem is that there are real-world reasons for wanting
to access supposedly private parts of a library.  And these reasons
may be beyond the library's initial design.

Maybe the ideal solution would be to somehow "colour code" the
methods, and have some kind of peril-sensitive sunglasses built into the  
IDE.

Hugh


> 2011/8/21 Gamehaxe <[hidden email]>
>
>> You can make your code harder to read, harder to write and slower buy  
>> why?
>>
> Because Joshua is writing libraries.
>
> A developer calling a method he isn't supposed to - I quote - "often  
> results
> in broken trains of thought, wasted time, and lost work. This is called  
> *user
> error*, but it isn’t. It is programmer or designer error. When we blame  
> the
> user, we teach them that technology is perfect and that the errors are  
> their
> own. Because technology is hard to use, we are teaching a generation to  
> be
> afraid of technology."
>
> This is a quote by Jono Xia about interfaces. I feel this applies to  
> APIs as
> well.
>
> If you have the choice, write a library that's hard to misuse and puts a
> smile on the user's face from the start; rather than a library that  
> requires
> hours of source code reading and sweating before it can be used without
> stack overflows and explosions.
>
> I personally feel merely using prefixes could go either way, depending on
> the context and the prefix itself.

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

Re: typedef alternative?

Alex Liebert
I think this is a limitation of haXe and not a problem with nme or hxcpp.

For NME, Hugh I agree with you that its sensible to keep the nme prefixed internals available publicly (I find myself using them occasionally and they're nice to have.)  But in a general sense the lack of a 'package only' access modifier in haXe is a limitation in my mind, even when designing APIs that are 'only for my use' and wanting them to remain clean.

From a purely practical standpoint, I think what Hugh says is about right; the typedef solution is very workable but comes at a performance cost when targeting CPP.

For Actuate's particular problem though; these methods are being exposed because of usage of basically Builder Pattern, where only the building methods are meant to be exposed but internal ones are showing up instead.  A performance/cleanliness balanced solution (been thinking about this a bit) would be something like (bad methods name are for illustrative purposes):

class PublicBuilder
{
  public function buildPart():PublicBuilder;
  public function buildAnotherPart():PublicBuilder;
}

class InternalBuilder extends PublicBuilder
{
  public function doInternalWork():Void;
  public function doOtherInternalWork():Void;
}

this way, all instances of the class would inherit from PublicBuilder; and in reality, all instances would actually be InternalBuilders; but returned as the type publicbuilder to limit the api outside of internal methods.

Alex




On Sun, Aug 21, 2011 at 10:02 AM, Gamehaxe <[hidden email]> wrote:
Well it seems you can choose to restrict access to "none",
"annoying and slow" or "mysterious name".  Least of 3 evils.

The main problem is that there are real-world reasons for wanting
to access supposedly private parts of a library.  And these reasons
may be beyond the library's initial design.

Maybe the ideal solution would be to somehow "colour code" the
methods, and have some kind of peril-sensitive sunglasses built into the IDE.

Hugh



2011/8/21 Gamehaxe <[hidden email]>

You can make your code harder to read, harder to write and slower buy why?

Because Joshua is writing libraries.

A developer calling a method he isn't supposed to - I quote - "often results
in broken trains of thought, wasted time, and lost work. This is called *user
error*, but it isn’t. It is programmer or designer error. When we blame the
user, we teach them that technology is perfect and that the errors are their
own. Because technology is hard to use, we are teaching a generation to be
afraid of technology."

This is a quote by Jono Xia about interfaces. I feel this applies to APIs as
well.

If you have the choice, write a library that's hard to misuse and puts a
smile on the user's face from the start; rather than a library that requires
hours of source code reading and sweating before it can be used without
stack overflows and explosions.

I personally feel merely using prefixes could go either way, depending on
the context and the prefix itself.

--
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: typedef alternative?

Pimm Hogeling
In reply to this post by Gamehaxe
2011/8/21 Gamehaxe <[hidden email]>
Maybe the ideal solution would be to somehow "colour code" the
methods, and have some kind of peril-sensitive sunglasses built into the IDE.
That's actually a very sexy idea. It would greatly reduce the chance of people misusing libraries.

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

Re: typedef alternative?

Nicolas Cannasse
Le 21/08/2011 21:04, Pimm Hogeling a écrit :
> 2011/8/21 Gamehaxe <[hidden email] <mailto:[hidden email]>>
>
>     Maybe the ideal solution would be to somehow "colour code" the
>     methods, and have some kind of peril-sensitive sunglasses built into
>     the IDE.
>
> That's actually a very sexy idea. It would greatly reduce the chance of
> people misusing libraries.

If you make sure to work only with colorblind people and use appropriate
setup you should be able to pull it out without the extra glasses.

Nicolas


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

Re: typedef alternative?

Justin Donaldson-3
I don't know why we keep reinventing the wheel here, this is a solved problem.  The best way to handle this is to put a piece of paper over the screen, and only cut out the parts you want the developer to see.  Mail each developer the piece of paper, and instruct them to tape it over their screen.  It's common courtesy to also send some tape.

Don't forget to version control your cutout along with your library.

-Justin


On Sun, Aug 21, 2011 at 2:08 PM, Nicolas Cannasse <[hidden email]> wrote:
Le 21/08/2011 21:04, Pimm Hogeling a écrit :
2011/8/21 Gamehaxe <[hidden email] <mailto:[hidden email]>>


   Maybe the ideal solution would be to somehow "colour code" the
   methods, and have some kind of peril-sensitive sunglasses built into
   the IDE.

That's actually a very sexy idea. It would greatly reduce the chance of
people misusing libraries.

If you make sure to work only with colorblind people and use appropriate setup you should be able to pull it out without the extra glasses.

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
|

hxcpp structural typing (was typedef alternative)

Johann Borck
In reply to this post by Alex Liebert
On 08/21/2011 07:38 PM, Alex Liebert wrote:
> From a purely practical standpoint, I think what Hugh says is about right; the typedef solution is
> very workable but comes at a performance cost when targeting CPP.
>
Hi,
without knowing about the internals of the current implementation, may I ask why that's the case?
C++ is one of not so many languages that support structural typing natively. It looks like a perfect
match, at least at first sight.

regards, Johann


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

Re: typedef alternative?

Michael Cann
In reply to this post by Justin Donaldson-3
HAHAHAHA :P

On 21 August 2011 22:38, Justin Donaldson <[hidden email]> wrote:
I don't know why we keep reinventing the wheel here, this is a solved problem.  The best way to handle this is to put a piece of paper over the screen, and only cut out the parts you want the developer to see.  Mail each developer the piece of paper, and instruct them to tape it over their screen.  It's common courtesy to also send some tape.

Don't forget to version control your cutout along with your library.

-Justin



On Sun, Aug 21, 2011 at 2:08 PM, Nicolas Cannasse <[hidden email]> wrote:
Le 21/08/2011 21:04, Pimm Hogeling a écrit :
2011/8/21 Gamehaxe <[hidden email] <mailto:[hidden email]>>


   Maybe the ideal solution would be to somehow "colour code" the
   methods, and have some kind of peril-sensitive sunglasses built into
   the IDE.

That's actually a very sexy idea. It would greatly reduce the chance of
people misusing libraries.

If you make sure to work only with colorblind people and use appropriate setup you should be able to pull it out without the extra glasses.

Nicolas



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


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



--
Mike Cann
http://www.mikecann.co.uk/


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

Re: typedef alternative?

Alex Liebert
In reply to this post by Nicolas Cannasse
Sorry to keep rehashing this but in all seriousness: is there a technical or philosophical reason not to support a package-internal access modifier in haXe?

On Sun, Aug 21, 2011 at 2:08 PM, Nicolas Cannasse <[hidden email]> wrote:
Le 21/08/2011 21:04, Pimm Hogeling a écrit :
2011/8/21 Gamehaxe <[hidden email] <mailto:[hidden email]>>


   Maybe the ideal solution would be to somehow "colour code" the
   methods, and have some kind of peril-sensitive sunglasses built into
   the IDE.

That's actually a very sexy idea. It would greatly reduce the chance of
people misusing libraries.

If you make sure to work only with colorblind people and use appropriate setup you should be able to pull it out without the extra glasses.

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: typedef alternative?

Nicolas Cannasse
Le 22/08/2011 01:29, Alex Liebert a écrit :
> Sorry to keep rehashing this but in all seriousness: is there a
> technical or philosophical reason not to support a package-internal
> access modifier in haXe?

More seriously : currently only Flash9 and C++ are affected by slowdown
while using typedefs, that's one of the reasons the issue has not be
looked at so far.

I'm not in favor of package-internal access modifier, it feels too
restrictive, not really flexible. haXe has been designed to put very low
restrictions on how you can access your own code or library code, while
still keeping a good level of type safety.

One of the thing I'm thinking about is to be able to explicitly declare
that you want to be able to access all fields of an object - including
its private fields.

That could be done with either additional syntax,
such as "import private MyClass;" or by using a special type-wrapper,
such as "var t : haxe.Private<MyClass> = new MyClass()" - in which case
you would only be able to access to private member fields, not static ones.

Best,
Nicolas

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

Re: typedef alternative?

Simon Richardson

On 22 Aug 2011, at 09:32, Nicolas Cannasse wrote:

> Le 22/08/2011 01:29, Alex Liebert a écrit :
>> Sorry to keep rehashing this but in all seriousness: is there a
>> technical or philosophical reason not to support a package-internal
>> access modifier in haXe?
>
> More seriously : currently only Flash9 and C++ are affected by slowdown while using typedefs, that's one of the reasons the issue has not be looked at so far.
>
> I'm not in favor of package-internal access modifier, it feels too restrictive, not really flexible. haXe has been designed to put very low restrictions on how you can access your own code or library code, while still keeping a good level of type safety.
>
> One of the thing I'm thinking about is to be able to explicitly declare that you want to be able to access all fields of an object - including its private fields.
>
> That could be done with either additional syntax,
> such as "import private MyClass;" or by using a special type-wrapper, such as "var t : haxe.Private<MyClass> = new MyClass()" - in which case you would only be able to access to private member fields, not static ones.

I'd be happy with that... :-)

>
> 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: typedef alternative?

Benjamin Dasnois
Hi,

Nicolas, you've always tried to keep the language and syntax simple. The thing is both of your proposal seem complex to me. I'm not really sure that using the type of a variable to change the visibility of fields is a good thing.

I will elaborate more on it later. At the moment, I'd be happy if we took note of the problem and thought of a solution for haXe 3 but we should certainly keep away from implementing that too quickly.

Regards,

On Mon, Aug 22, 2011 at 10:46 AM, Simon Richardson <[hidden email]> wrote:

On 22 Aug 2011, at 09:32, Nicolas Cannasse wrote:

> Le 22/08/2011 01:29, Alex Liebert a écrit :
>> Sorry to keep rehashing this but in all seriousness: is there a
>> technical or philosophical reason not to support a package-internal
>> access modifier in haXe?
>
> More seriously : currently only Flash9 and C++ are affected by slowdown while using typedefs, that's one of the reasons the issue has not be looked at so far.
>
> I'm not in favor of package-internal access modifier, it feels too restrictive, not really flexible. haXe has been designed to put very low restrictions on how you can access your own code or library code, while still keeping a good level of type safety.
>
> One of the thing I'm thinking about is to be able to explicitly declare that you want to be able to access all fields of an object - including its private fields.
>
> That could be done with either additional syntax,
> such as "import private MyClass;" or by using a special type-wrapper, such as "var t : haxe.Private<MyClass> = new MyClass()" - in which case you would only be able to access to private member fields, not static ones.

I'd be happy with that... :-)

>
> Best,
> Nicolas
>
> --
> 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: typedef alternative?

Nicolas Cannasse
Le 22/08/2011 10:54, Benjamin Dasnois a écrit :
> Hi,
>
> Nicolas, you've always tried to keep the language and syntax simple. The
> thing is both of your proposal seem complex to me. I'm not really sure
> that using the type of a variable to change the visibility of fields is
> a good thing.

That's questionable.

After all so far we are already doing that with private fields structures :

var t : { private var p : Int; } = new MyClass();

haxe.Private<T> would only be a shortcut that also keep the original
type for optimization purposes.

> I will elaborate more on it later. At the moment, I'd be happy if we
> took note of the problem and thought of a solution for haXe 3 but we
> should certainly keep away from implementing that too quickly.

Sure, I was just throwing ideas, I didn't start any implementation yet.
You (and everybody else) are welcome to propose better alternatives.

Best,
Nicolas

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

Re: typedef alternative?

bubblebenj
Just wonder, what not simply using the C++ friend mechanism ?

On Mon, Aug 22, 2011 at 11:00 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 22/08/2011 10:54, Benjamin Dasnois a écrit :

Hi,

Nicolas, you've always tried to keep the language and syntax simple. The
thing is both of your proposal seem complex to me. I'm not really sure
that using the type of a variable to change the visibility of fields is
a good thing.

That's questionable.

After all so far we are already doing that with private fields structures :

var t : { private var p : Int; } = new MyClass();

haxe.Private<T> would only be a shortcut that also keep the original type for optimization purposes.


I will elaborate more on it later. At the moment, I'd be happy if we
took note of the problem and thought of a solution for haXe 3 but we
should certainly keep away from implementing that too quickly.

Sure, I was just throwing ideas, I didn't start any implementation yet. You (and everybody else) are welcome to propose better alternatives.


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: typedef alternative?

luca deltodesco
If we wanted to keep things totally accessible, could even reverse it. so that you declare you want to be friends with a class, and then gain access to it's privates. Rather than the class saying who it will allow to be friends with it.

Then get the benefits of 'not' exposing everything by default, but if you really want to get to the hidden stuff, just befriend it and go ahead.


Date: Mon, 22 Aug 2011 11:47:21 +0200
Subject: Re: [haXe] typedef alternative?
From: [hidden email]
To: [hidden email]

Just wonder, what not simply using the C++ friend mechanism ?

On Mon, Aug 22, 2011 at 11:00 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 22/08/2011 10:54, Benjamin Dasnois a écrit :

Hi,

Nicolas, you've always tried to keep the language and syntax simple. The
thing is both of your proposal seem complex to me. I'm not really sure
that using the type of a variable to change the visibility of fields is
a good thing.

That's questionable.

After all so far we are already doing that with private fields structures :

var t : { private var p : Int; } = new MyClass();

haxe.Private<T> would only be a shortcut that also keep the original type for optimization purposes.


I will elaborate more on it later. At the moment, I'd be happy if we
took note of the problem and thought of a solution for haXe 3 but we
should certainly keep away from implementing that too quickly.

Sure, I was just throwing ideas, I didn't start any implementation yet. You (and everybody else) are welcome to propose better alternatives.


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: typedef alternative?

Gamehaxe
In reply to this post by Nicolas Cannasse
Hi,
Yes, this seems better than the status quo.
The way I think of it is not really at a class level - more at
the member level - and then at the "use" time. like:

class T { private var P; }
var t = new T();

Something like "untyped":

var x = unprotected{t.P};

Or this syntax may be better: (good for auto completion maybe, no new  
keyword)
x = t.private.P

Package level would also be nice - but it sufferers from some of the
same drawbacks as "friend", but to a lesser extent.

Hugh


> Le 22/08/2011 10:54, Benjamin Dasnois a écrit :
>> Hi,
>>
>> Nicolas, you've always tried to keep the language and syntax simple. The
>> thing is both of your proposal seem complex to me. I'm not really sure
>> that using the type of a variable to change the visibility of fields is
>> a good thing.
>
> That's questionable.
>
> After all so far we are already doing that with private fields  
> structures :
>
> var t : { private var p : Int; } = new MyClass();
>
> haxe.Private<T> would only be a shortcut that also keep the original  
> type for optimization purposes.
>
>> I will elaborate more on it later. At the moment, I'd be happy if we
>> took note of the problem and thought of a solution for haXe 3 but we
>> should certainly keep away from implementing that too quickly.
>
> Sure, I was just throwing ideas, I didn't start any implementation yet.  
> You (and everybody else) are welcome to propose better alternatives.
>
> Best,
> Nicolas

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

Re: typedef alternative?

Nicolas Cannasse
In reply to this post by luca deltodesco
Le 22/08/2011 12:07, luca deltodesco a écrit :
> If we wanted to keep things totally accessible, could even reverse it.
> so that you declare you want to be friends with a class, and then gain
> access to it's privates. Rather than the class saying who it will allow
> to be friends with it.

Yes, reverse-friend is another possibility.

The only issue is that you might want to only have private access in
some specific methods of your class, and still hide private methods in
other methods (as well as subclasses).

That's why I think it should be part of the type declaration itself.

Nicolas

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

Re: typedef alternative?

bubblebenj
What you are describing as reverse-friend is more like extortion.
I have some nice key words proposal (used like a cast ):
var x = extort( y.myPrivateCash );

It could also be force, loot, steal, exploit and why not hustle or pimp.

Ben

On Mon, Aug 22, 2011 at 12:50 PM, Nicolas Cannasse <[hidden email]> wrote:
Le 22/08/2011 12:07, luca deltodesco a écrit :

If we wanted to keep things totally accessible, could even reverse it.
so that you declare you want to be friends with a class, and then gain
access to it's privates. Rather than the class saying who it will allow
to be friends with it.

Yes, reverse-friend is another possibility.

The only issue is that you might want to only have private access in some specific methods of your class, and still hide private methods in other methods (as well as subclasses).

That's why I think it should be part of the type declaration itself.


Nicolas

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


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