Protected / Namespace

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

Protected / Namespace

Tarwin Stroh-Spijer
Hi,

I know this has been talked about before, and Nicolas is against adding a protected keyword, but I just want to put my hand up for it again (or namespaces, but they confuse me a little).

I was at a haxe meetup, about 10 of us, in San Francisco last week, and this was one of the things that came up there.

Until recently I never had the need for 'protected', as I generally worked by myself, or with only one other person, and only on "get ti done quickly" projects. Now I've started working on larger projects, where one person is working on APIs that other people are using, and I now realise how important "protected" is, if only to make sure code is used as expected, or even code completion isn't full of useless fields.

Anyway, hope this is useful discussion.

Regards,


Tarwin Stroh-Spijer
_______________________

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

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

Re: Protected / Namespace

Franco Ponticelli
I must admit that I have the same feelings. The "protected" modifier has an important semantic value that is a lot more explicit than using conventions like prefixing fields with "_" when they are to be considered as true privates.

Franco

On Mon, Oct 31, 2011 at 5:58 PM, Tarwin Stroh-Spijer <[hidden email]> wrote:
Hi,

I know this has been talked about before, and Nicolas is against adding a protected keyword, but I just want to put my hand up for it again (or namespaces, but they confuse me a little).

I was at a haxe meetup, about 10 of us, in San Francisco last week, and this was one of the things that came up there.

Until recently I never had the need for 'protected', as I generally worked by myself, or with only one other person, and only on "get ti done quickly" projects. Now I've started working on larger projects, where one person is working on APIs that other people are using, and I now realise how important "protected" is, if only to make sure code is used as expected, or even code completion isn't full of useless fields.

Anyway, hope this is useful discussion.

Regards,


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="+61380605321" target="_blank">+61 3 8060 5321
_______________________

--
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: Protected / Namespace

Cauê W.
In reply to this post by Tarwin Stroh-Spijer
hey Tarwin! How are you?

We've completely got rid of the namespace problem with macros at the company I work.

What we've done is made a macro that will create a Typedef for us of all the types that have a specified meta added to it.

I can show you some code, but it`s very sketched up. What it does is emulate what is done in e.g. away3dlite, but automatically with macros, and with possibilites of having numerous meta definitions, simulating really how a namespace would be.

About true privates, I think it's really out of how haxe works, and would have some problems (like re-definition of private variables), and could be sorted out with proper namespaces with metadata handling

2011/10/31 Tarwin Stroh-Spijer <[hidden email]>
Hi,

I know this has been talked about before, and Nicolas is against adding a protected keyword, but I just want to put my hand up for it again (or namespaces, but they confuse me a little).

I was at a haxe meetup, about 10 of us, in San Francisco last week, and this was one of the things that came up there.

Until recently I never had the need for 'protected', as I generally worked by myself, or with only one other person, and only on "get ti done quickly" projects. Now I've started working on larger projects, where one person is working on APIs that other people are using, and I now realise how important "protected" is, if only to make sure code is used as expected, or even code completion isn't full of useless fields.

Anyway, hope this is useful discussion.

Regards,


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="+61380605321" target="_blank">+61 3 8060 5321
_______________________

--
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: Protected / Namespace

Michael Baczynski-2
In reply to this post by Franco Ponticelli
IMHO I think a protected keyword isn't needed:

- I always prefix fields and functions for internal use with an underscore, so where's the problem?
You don't "accidentally" call a non-public member - if you do so you know exactly what you are doing.
- Private and public are simple concepts, protected is a bit blurry.
- It makes your code much more extensible.
- I doesn't affect auto-completion, since all private members are grouped together thanks to the prefix.

best,
michael

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

Re: Protected / Namespace

Franco Ponticelli
- I always prefix fields and functions for internal use with an underscore, so where's the problem? You don't "accidentally" call a non-public member - if you do so you know exactly what you are doing.
 
There is no problem in a convention besides being a convention. 

- Private and public are simple concepts, protected is a bit blurry.

I don't really think is blurry. What is blurry about "you can redefine that method if you want but should not be exposed in your public api"?
 
- It makes your code much more extensible.

Maybe but it opens for potential disaster. The developer "must" know exactly what is going on in the library he is using to override a private without risking to do a mess.
 
- I doesn't affect auto-completion, since all private members are grouped together thanks to the prefix.

In my opinion it really does just by simplying being there even if they should not.

Franco

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

Re: Protected / Namespace

Elsass Philippe
I'd like to have at least 'protected' - a name convention isn't enough imho.

On Mon, Oct 31, 2011 at 7:24 PM, Franco Ponticelli <[hidden email]> wrote:
- I always prefix fields and functions for internal use with an underscore, so where's the problem? You don't "accidentally" call a non-public member - if you do so you know exactly what you are doing.
 
There is no problem in a convention besides being a convention. 

- Private and public are simple concepts, protected is a bit blurry.

I don't really think is blurry. What is blurry about "you can redefine that method if you want but should not be exposed in your public api"?
 
- It makes your code much more extensible.

Maybe but it opens for potential disaster. The developer "must" know exactly what is going on in the library he is using to override a private without risking to do a mess.
 
- I doesn't affect auto-completion, since all private members are grouped together thanks to the prefix.

In my opinion it really does just by simplying being there even if they should not.

Franco

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



--
Philippe

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

Re: Protected / Namespace

Michael Baczynski-2
In reply to this post by Franco Ponticelli
> Maybe but it opens for potential disaster. The developer "must" know exactly what is going on in the
> library he is using to override a private without risking to do a mess.

exactly - that's why documenting your code is so important ;)

>
>     - I doesn't affect auto-completion, since all private members are grouped together thanks to the
>     prefix.
>
>
> In my opinion it really does just by simplying being there even if they should not.

but then for a developer (not end-user) it makes extending and maintaining your code easier when
internal members are shown in auto-completion.

best,
michael


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

Re: Protected / Namespace

Nicolas Cannasse
In reply to this post by Tarwin Stroh-Spijer
Le 31/10/2011 18:58, Tarwin Stroh-Spijer a écrit :
> Hi,
>
> I know this has been talked about before, and Nicolas is against adding
> a protected keyword, but I just want to put my hand up for it again (or
> namespaces, but they confuse me a little).
>
> I was at a haxe meetup, about 10 of us, in San Francisco last week, and
> this was one of the things that came up there.

Actually, haXe "private" is exactly the same as AS3/Java "protected".

It means that you can override a private method in subclasses.

haXe however does not allow you to define "Java private methods" (the
one that are not visible in subclasses).

The reason is that it is the philosophy of haXe not to prevent a
developer from reusing other people code. And since "override" is
mandatory in these cases, it's not like you can actually override a
superclass method by accident.

The only "issue" left is to find a way how to explicitly "force" access
to private field/method, which is useful when you have an API consisting
of several related classes that want to access each others private fields.

This is currently done by defining a structure that list private fields:

typedef Priv = {
    private var _x : Int;
    private function innerAPI( v : Int );
}

Then you can do things such as :

var p : Priv = new MyApiClass();
p.innerAPI(p._x++);

However this is maybe not the best solution since :

a) you need to explicitly list all fields you want to access
b) you are using duck-typing access (with a structure) which is slower
on "typed" platforms such as Flash or CPP

Best,
Nicolas

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

Re: Protected / Namespace

Franco Ponticelli
In reply to this post by Michael Baczynski-2


On Mon, Oct 31, 2011 at 6:35 PM, Michael Baczynski <[hidden email]> wrote:
Maybe but it opens for potential disaster. The developer "must" know exactly what is going on in the
library he is using to override a private without risking to do a mess.

exactly - that's why documenting your code is so important ;)

I hate documenting my code ... and I like when the code is self documenting ;)

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

Re: Protected / Namespace

Cauê W.
In reply to this post by Nicolas Cannasse
 Okay, I realized my "speed writing" wasn't clear at all : P

What I meant to say is that we`ve created a macro that does that:
 

typedef Priv = {
  private var _x : Int;
  private function innerAPI( v : Int );
}

automatically, like that:

Test.hx
class Test
{
@my_ns var protected1:Int;
@other_ns var protected2:Bool;
@other_ns function void():Void {}
}

typedef MyTestFriendOtherNS = haxe.macro.MacroType<{comtacti.tools.macro.Namespace.build("Test", "other_ns")}>;

//this will build it as
typedef MyTestFriendOtherNS = { private var protected2:Bool; private function void():Void; };

The cool part about this is that you can bundle it with using with something like that:

class MyTestFriendOtherNS_NS
{
public static inline function other_ns(t:Test):MyTestFriendOtherNS
{
return t;
}

it seems that inline optimizes this making the dynamic access go away in this case. I haven't seen the generated C++ code, but in swf there really is no slowdown at all by calling a function like that or if it's a public function

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

Re: Protected / Namespace

Franco Ponticelli
In reply to this post by Nicolas Cannasse
Actually, haXe "private" is exactly the same as AS3/Java "protected".
It means that you can override a private method in subclasses.
haXe however does not allow you to define "Java private methods" (the one that are not visible in subclasses).

That's correct but being able to hide some private methods is really important to me.
  
a) you need to explicitly list all fields you want to access
b) you are using duck-typing access (with a structure) which is slower on "typed" platforms such as Flash or CPP

That is pretty big too and using typedefs is nice but a little hackish in my opinion.

Franco

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

Re: Protected / Namespace

Tarwin Stroh-Spijer
In reply to this post by Franco Ponticelli
http://download.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html

I think in Java protected allow classes in the same package to access, which is where making libraries is a good thing.

I know there is ways to make friend class helpers, or even do this using macros, but this just gets confusing!


Tarwin Stroh-Spijer
_______________________

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


On Mon, Oct 31, 2011 at 11:46 AM, Franco Ponticelli <[hidden email]> wrote:


On Mon, Oct 31, 2011 at 6:35 PM, Michael Baczynski <[hidden email]> wrote:
Maybe but it opens for potential disaster. The developer "must" know exactly what is going on in the
library he is using to override a private without risking to do a mess.

exactly - that's why documenting your code is so important ;)

I hate documenting my code ... and I like when the code is self documenting ;)

--
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: Protected / Namespace

Tarwin Stroh-Spijer
In reply to this post by Franco Ponticelli
Actually, a quick thought. If "protected" was slightly different than in Java, in that it let classes access protected vars/methods in the same "or child" packages, that would make sense I think.

And as you point out (Franco / Nicolas) this is only compile-time anyway, so it doesn't add any overhead.

Regards,


Tarwin Stroh-Spijer
_______________________

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


On Mon, Oct 31, 2011 at 11:50 AM, Franco Ponticelli <[hidden email]> wrote:
Actually, haXe "private" is exactly the same as AS3/Java "protected".
It means that you can override a private method in subclasses.
haXe however does not allow you to define "Java private methods" (the one that are not visible in subclasses).

That's correct but being able to hide some private methods is really important to me.
  
a) you need to explicitly list all fields you want to access
b) you are using duck-typing access (with a structure) which is slower on "typed" platforms such as Flash or CPP

That is pretty big too and using typedefs is nice but a little hackish in my opinion.

Franco

--
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: Protected / Namespace

Nicolas Cannasse
In reply to this post by Franco Ponticelli
Le 31/10/2011 19:50, Franco Ponticelli a écrit :
>     Actually, haXe "private" is exactly the same as AS3/Java "protected".
>     It means that you can override a private method in subclasses.
>     haXe however does not allow you to define "Java private methods"
>     (the one that are not visible in subclasses).
>
>
> That's correct but being able to hide some private methods is really
> important to me.

Could you detail why ?

Best,
Nicolas

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

Re: Protected / Namespace

Nicolas Cannasse
In reply to this post by Tarwin Stroh-Spijer
Le 31/10/2011 19:58, Tarwin Stroh-Spijer a écrit :
> Actually, a quick thought. If "protected" was slightly different than in
> Java, in that it let classes access protected vars/methods in the same
> "or child" packages, that would make sense I think.

This would be quite an unsafe behavior by default.

I'm not planning to change the way haXe "private" works, or introduce
another keyword such as "protected".

The reason is that having package-restricted access is just a
convention, while I prefer something more declarative, which doesn't
impact the package you're choosing to put your classes in.

There _should_ be a way to bypass access restrictions on a given class
in a typed manner since - while they are often useful to design apis -
they tend to limit the amount of things you can actually do. And this
should be done without having to modify the original class.

That's why I'm still quite happy with the "private structure" behavior
right now since it reach almost all the goals apart performances. The
fact that it needs more writing also helps to reduce the amount of time
you will rely on it, which is also a good thing IMHO.

Best,
Nicolas

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

Re: Protected / Namespace

Franco Ponticelli
In reply to this post by Nicolas Cannasse
When I want to share my code with other developers I don't want to worry about the fact that they might call functions that are supposed to be controlled just by the super class. Even if that is not too frequent because I can usually avoid the issue by further breaking down the composition of my classes, it is still an option I'd like to have.

Franco

On Mon, Oct 31, 2011 at 7:34 PM, Nicolas Cannasse <[hidden email]> wrote:
Le 31/10/2011 19:50, Franco Ponticelli a écrit :

   Actually, haXe "private" is exactly the same as AS3/Java "protected".
   It means that you can override a private method in subclasses.
   haXe however does not allow you to define "Java private methods"
   (the one that are not visible in subclasses).


That's correct but being able to hide some private methods is really
important to me.

Could you detail why ?


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: Protected / Namespace

danielku15
In reply to this post by Nicolas Cannasse
Nicolas Cannasse wrote
Could you detail why ?
Hi everybody.

Each time you use haXe for creating a library rather than a whole application the concept of private/protected is needed. Each modern OOP language provides a public/protected/private mechanism and even standards like UML include that concept, but haXe doesn't. There's always a "you can live without it": "Who needs OOP? you can do everything in languages like C!". You simply need that stuff to make clean code which meets the concepts you try to implement.

A more practical example: If you want to create a library rather than a full application using haxe you open the doors for everyone to access non-public elements. If you use some special encryption and security stuff everyone can access your secure data by simply making a subclass of the desired class.  

IMHO each OOP language (including) haXe should provide concepts known by each programmer including a private/protected separation. The sad problem is: There are even more differences between haXe and other OOP languages like method overloads.

A lot of missing stuff needs to be implemented by conventions and macros. But this is and stays a "workaround solution". A language needs to improve and provide new elements, not only the library needs improvements. That's exactly what Java does wrong: No language changes, only API changes. C# does it right: The language and the API improves. Java has about 4-5 Systems for implementing events alone in the JDK. C# has 1 keyword for it.

It is not correct to ignore change requests because not everybody needs the change. If there are people who need/want the change and it is a good idea, it should get considered.

To bad I see another behaviour every time a suggestion is made: Some of the haXe veterans simply slam the ideas down using the same words over and over again: "There's no need for that, you can do a workaround".

The haXe community is simply awesome and haXe it self too, but it seems changes to haXe itself are an unwelcome sight.

P.s. Sorry if I departed from the topic a bit.

Reply | Threaded
Open this post in threaded view
|

Re: Protected / Namespace

Tarwin Stroh-Spijer
So a really quick example, and one I'm working with at the moment:

Data API for server-side application

There is one developer making the API. It has quite a few classes, most of which you access through an API object. There are classes for handling caching on both a database and on memcache, and these should ONLY be accessed from the API class itself. There are also classes that have a few methods that would be useful to access externally from the API package, but most of which should only be used by the API itself.

---

I guess a "package" keyword would be a compromise, as "protected" is used in other languages. You could put this on methods / vars to say that only items within that same package can access it.

This is pretty much like a badly done manual namespace declaration though, again which I never realised I needed until I did. Namespaces solve the same kind of 'access issue'. What other people want 'protected' for is slightly different though I guess.

I do worry that your insistence on not having these, even though the community seems to want them quite a lot, is a personal preference rather than what's best for the language. It is also something that confuses new users (as does the lack of "for (i=0; i<n; i++)". It may not be "best practice" but it's "nice" for new users - or converting code from other languages now that I think of it.

Hope that's a better, more full, explanation.

Tarwin Stroh-Spijer
_______________________

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


On Mon, Oct 31, 2011 at 1:21 PM, danielku15 <[hidden email]> wrote:

Nicolas Cannasse wrote:
>
> Could you detail why ?
>

Hi everybody.

Each time you use haXe for creating a library rather than a whole
application the concept of private/protected is needed. Each modern OOP
language provides a public/protected/private mechanism and even standards
like UML include that concept, but haXe doesn't. There's always a "you can
live without it": "Who needs OOP? you can do everything in languages like
C!". You simply need that stuff to make clean code which meets the concepts
you try to implement.

A more practical example: If you want to create a library rather than a full
application using haxe you open the doors for everyone to access non-public
elements. If you use some special encryption and security stuff everyone can
access your secure data by simply making a subclass of the desired class.

IMHO each OOP language (including) haXe should provide concepts known by
each programmer including a private/protected separation. The sad problem
is: There are even more differences between haXe and other OOP languages
like method overloads.

A lot of missing stuff needs to be implemented by conventions and macros.
But this is and stays a "workaround solution". A language needs to improve
and provide new elements, not only the library needs improvements. That's
exactly what Java does wrong: No language changes, only API changes. C# does
it right: The language and the API improves. Java has about 4-5 Systems for
implementing events alone in the JDK. C# has 1 keyword for it.

It is not correct to ignore change requests because not everybody needs the
change. If there are people who need/want the change and it is a good idea,
it should get considered.

To bad I see another behaviour every time a suggestion is made: Some of the
haXe veterans simply slam the ideas down using the same words over and over
again: "There's no need for that, you can do a workaround".

The haXe community is simply awesome and haXe it self too, but it seems
changes to haXe itself are an unwelcome sight.

P.s. Sorry if I departed from the topic a bit.



--
View this message in context: http://haxe.1354130.n2.nabble.com/Protected-Namespace-tp6949146p6949629.html
Sent from the Haxe mailing list archive at Nabble.com.

--
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: Re: [haXe] Protected / Namespace

Rob Fell
In reply to this post by Nicolas Cannasse
Hi,

IIRC the "Open to extension, closed to modification" principle doesn't
work safely without "private"'s scope being limited only to it's own class.

I find it easier to consider why retrospectively:

1) I create class "Foo".
2) Developer X extends "Foo" to become "FooX" (and introduces some new
private members - e.g. "private var _bar").
3) Later I modify / refactor my implementation of "Foo" and introduce
new private members (I also add "private var _bar").
4) But I cannot know of "FooX"'s private members ... hence Developer X
has retrospective risk of broken subclasses through member name collision.

To be safe I could adopt a fully qualified prefix to private members
(e.g. _package_class_member) ... and remember to document why this
convention is needed.

Best, Rob


On 11:59 AM, Nicolas Cannasse wrote:

> Le 31/10/2011 19:50, Franco Ponticelli a écrit :
>>     Actually, haXe "private" is exactly the same as AS3/Java
>> "protected".
>>     It means that you can override a private method in subclasses.
>>     haXe however does not allow you to define "Java private methods"
>>     (the one that are not visible in subclasses).
>>
>>
>> That's correct but being able to hide some private methods is really
>> important to me.
>
> Could you detail why ?
>
> Best,
> Nicolas
>
>


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

Re: Re: [haXe] Protected / Namespace

jamesbjackson
Guys,

I totally agree with Nicolas on this.. I heavy use JavaScript & Node.JS and there is actually no notion of private or protected really, if you want to control a API then the programmer only codes against a public Interface to compile against, this means they can access any private functions this is what apple do with IOS as it in breach of the terms of the usage to access private methods directly..

Just my thoughts...

James
12