Private access control (draft)

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

Private access control (draft)

Nicolas Cannasse
Hi,

Following recent discussions about the way you should be away to access
other classes private variables and methods, I've written a draft about
a new proposed feature called "Access Control" :

http://haxe.org/manual/acl

Thank you for your feedback, especially about the naming choice of
@:give/@:access which I'm not 100% happy with, but it's not very easy to
find better (please prove me wrong).

Best,
Nicolas

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

Re: Private access control (draft)

laurence taylor
@:give and @:take? It also happens to be an English idiom.

On Sun, Nov 6, 2011 at 9:59 AM, Nicolas Cannasse <[hidden email]> wrote:
Hi,

Following recent discussions about the way you should be away to access other classes private variables and methods, I've written a draft about a new proposed feature called "Access Control" :

http://haxe.org/manual/acl

Thank you for your feedback, especially about the naming choice of @:give/@:access which I'm not 100% happy with, but it's not very easy to find better (please prove me wrong).

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: Private access control (draft)

John Plsek
In reply to this post by Nicolas Cannasse
C++ (for one) uses "friend" to give access

I don't mind, @:give though

Not sure about @:access - why not @:take

My 2 cents

John

On 6 November 2011 19:59, Nicolas Cannasse <[hidden email]> wrote:
Hi,

Following recent discussions about the way you should be away to access other classes private variables and methods, I've written a draft about a new proposed feature called "Access Control" :

http://haxe.org/manual/acl

Thank you for your feedback, especially about the naming choice of @:give/@:access which I'm not 100% happy with, but it's not very easy to find better (please prove me wrong).

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: Private access control (draft)

Nicolas Cannasse
In reply to this post by laurence taylor
Le 06/11/2011 10:10, Laurence Taylor a écrit :
> @:give and @:take? It also happens to be an English idiom.

"giving access" seems natural to me but "taking access" seems a bit od.
I'm not a native speaker.

Best,
Nicolas

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

Re: Private access control (draft)

David Elahee
Hi,

This is a great feature, that was really needed for us engine writers that want to write fast and simple architecture without that crappy friendship/interfaces bloat.

Thanks a lot,
David.


Le dimanche 6 novembre 2011, Nicolas Cannasse <[hidden email]> a écrit :
> Le 06/11/2011 10:10, Laurence Taylor a écrit :
>>
>> @:give and @:take? It also happens to be an English idiom.
>
> "giving access" seems natural to me but "taking access" seems a bit od. I'm not a native speaker.
>
> Best,
> Nicolas
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
David Elahee




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

Re: Private access control (draft)

Mihail Ivanchev
In reply to this post by Nicolas Cannasse
Hi,

I do not agree with the proposed features nor do I find them any useful. Accessing private fields as in the way of C++'s "friend" keyword is dangerous and lazy programming that's never really needed, because better patterns are available, such as the Factory in this case.

class A
{
      // Private constructor
      function new() { }

      // External interfaces visible to the user
      function doXWithA() { }
}

// Internal representation of A
//
private class AInternal
{
      public var foo_boo;

      public function new() { }
      public function internalOp() {}
}

// Publically available factory for A
//
class Factory
{
      public static function create(): A
      {
          return new AInternal();
      }
}

No need of additional magic as it's just confusing for both reviewers and coders.

Cheers,
Mihail

On Sun, Nov 6, 2011 at 9:59 AM, Nicolas Cannasse <[hidden email]> wrote:
Hi,

Following recent discussions about the way you should be away to access other classes private variables and methods, I've written a draft about a new proposed feature called "Access Control" :

http://haxe.org/manual/acl

Thank you for your feedback, especially about the naming choice of @:give/@:access which I'm not 100% happy with, but it's not very easy to find better (please prove me wrong).

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: Private access control (draft)

jlm@justinfront.net
In reply to this post by Nicolas Cannasse
if I import the class I would expect not to put a full qualified class  
path.  If two classes could be possible I would want it to infer the  
correct type.

for example with the adding keyboard listeners from awhile back I had  
two classes that I could 'using' one for Int, and one for  
Strings( letters ) that I could get to easily wire up the key stroke  
events.  If these were private static functions... I would want the  
function that I had given access to, to be able to infer the correct  
type even though this is being setup by a macro... this is why I  
wonder if macro is possible/suitable or if this needs to be deeper in  
haXe?

I think 'access' is not ideal since we talk about giving access or  
having access, the concept of taking access seems like freedom of  
information act in the uk so maybe free would work, but 'take' does  
not sound good.  For clarity I suggest a few alternatives appended  
with Access.

@:giveAccess( SecretService )
@:freeAccess( Secrets )

@:giveAccess( SecretService)
@:permitAccess(Secrets )

@:giveAccess( SecretService)
@:haveAccess( Secrets )

I think maybe the more verbose style I suggest, will make it easier  
for new users?

Or maybe a system where you can setup the access type from a single  
macro

@:Access( SecretService, Give );
@:Access( Secret, Have );
@:Access( Secrets, TwoWay );

@:Access( SecretService, OUT );
@:Access( Secret, IN );
@:Access( Secrets, BOTH );



On 6 Nov 2011, at 08:59, Nicolas Cannasse wrote:

> Hi,
>
> Following recent discussions about the way you should be away to  
> access other classes private variables and methods, I've written a  
> draft about a new proposed feature called "Access Control" :
>
> http://haxe.org/manual/acl
>
> Thank you for your feedback, especially about the naming choice of  
> @:give/@:access which I'm not 100% happy with, but it's not very  
> easy to find better (please prove me wrong).
>
> 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: Private access control (draft)

bubblebenj
Mikael, I don't understand why friend class concept being lazy and dangerous (maybe you can enlighten me), neither why factory are better patterns, and last I don't even understand how your example work.

Friend class is an easy concept to grasp.
I'm no monster programmer, but keeping thing simple are IMO the best way to maintain your code.

btw +1 for the friend keyword since it really looks like it behaves like the cpp friend concept.

Ben

On Sun, Nov 6, 2011 at 11:42 AM, [hidden email] <[hidden email]> wrote:
if I import the class I would expect not to put a full qualified class path.  If two classes could be possible I would want it to infer the correct type.

for example with the adding keyboard listeners from awhile back I had two classes that I could 'using' one for Int, and one for Strings( letters ) that I could get to easily wire up the key stroke events.  If these were private static functions... I would want the function that I had given access to, to be able to infer the correct type even though this is being setup by a macro... this is why I wonder if macro is possible/suitable or if this needs to be deeper in haXe?

I think 'access' is not ideal since we talk about giving access or having access, the concept of taking access seems like freedom of information act in the uk so maybe free would work, but 'take' does not sound good.  For clarity I suggest a few alternatives appended with Access.

@:giveAccess( SecretService )
@:freeAccess( Secrets )

@:giveAccess( SecretService)
@:permitAccess(Secrets )

@:giveAccess( SecretService)
@:haveAccess( Secrets )

I think maybe the more verbose style I suggest, will make it easier for new users?

Or maybe a system where you can setup the access type from a single macro

@:Access( SecretService, Give );
@:Access( Secret, Have );
@:Access( Secrets, TwoWay );

@:Access( SecretService, OUT );
@:Access( Secret, IN );
@:Access( Secrets, BOTH );




On 6 Nov 2011, at 08:59, Nicolas Cannasse wrote:

Hi,

Following recent discussions about the way you should be away to access other classes private variables and methods, I've written a draft about a new proposed feature called "Access Control" :

http://haxe.org/manual/acl

Thank you for your feedback, especially about the naming choice of @:give/@:access which I'm not 100% happy with, but it's not very easy to find better (please prove me wrong).

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: Private access control (draft)

bubblebenj
Also it's nice to be able to give friendship to a whole package :D

Ben

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

Re: Private access control (draft)

Mihail Ivanchev
In reply to this post by bubblebenj
Friend class concept violates basic principles of OO design and encapsulation. Clearly, a private variable is part of the internal state of an object and no other object should access that. When you use friendly classes you say "I have a private var which is not really private, because someone else than I has access" which is in effect an oxymoron. 99,99% of the cases you use friendly variables you have a very bad and wrong design of in your architecture. Almost all cases of apparatent friendship relations are solved by giving the user an external interface / class:

interface IInterface
{
      function allowedOperation();
}

implementing that interface privately so that other internal code can communicate with your internal representation (your "relationship"):

class InternalRepresentation implements IInterface
{
     function someFunctionThatInternalCodeCanCallInsteadOfFriendlyFields()
     {
     }
}

and you return InternalRepresentation to the outside world.

Do not ruin good design for simplicity, ever.

Regards,
Mihail

On Sun, Nov 6, 2011 at 1:13 PM, benjamin Dubois <[hidden email]> wrote:
Mikael, I don't understand why friend class concept being lazy and dangerous (maybe you can enlighten me), neither why factory are better patterns, and last I don't even understand how your example work.

Friend class is an easy concept to grasp.
I'm no monster programmer, but keeping thing simple are IMO the best way to maintain your code.

btw +1 for the friend keyword since it really looks like it behaves like the cpp friend concept.

Ben

On Sun, Nov 6, 2011 at 11:42 AM, [hidden email] <[hidden email]> wrote:
if I import the class I would expect not to put a full qualified class path.  If two classes could be possible I would want it to infer the correct type.

for example with the adding keyboard listeners from awhile back I had two classes that I could 'using' one for Int, and one for Strings( letters ) that I could get to easily wire up the key stroke events.  If these were private static functions... I would want the function that I had given access to, to be able to infer the correct type even though this is being setup by a macro... this is why I wonder if macro is possible/suitable or if this needs to be deeper in haXe?

I think 'access' is not ideal since we talk about giving access or having access, the concept of taking access seems like freedom of information act in the uk so maybe free would work, but 'take' does not sound good.  For clarity I suggest a few alternatives appended with Access.

@:giveAccess( SecretService )
@:freeAccess( Secrets )

@:giveAccess( SecretService)
@:permitAccess(Secrets )

@:giveAccess( SecretService)
@:haveAccess( Secrets )

I think maybe the more verbose style I suggest, will make it easier for new users?

Or maybe a system where you can setup the access type from a single macro

@:Access( SecretService, Give );
@:Access( Secret, Have );
@:Access( Secrets, TwoWay );

@:Access( SecretService, OUT );
@:Access( Secret, IN );
@:Access( Secrets, BOTH );




On 6 Nov 2011, at 08:59, Nicolas Cannasse wrote:

Hi,

Following recent discussions about the way you should be away to access other classes private variables and methods, I've written a draft about a new proposed feature called "Access Control" :

http://haxe.org/manual/acl

Thank you for your feedback, especially about the naming choice of @:give/@:access which I'm not 100% happy with, but it's not very easy to find better (please prove me wrong).

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


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

Re: Private access control (draft)

bubblebenj
I still don't get how you restrict access with interface.
OK you don't have access to the private field, but the problem is only transferred to implementation of the interface (not sure I'm clear).
You may still want to be capable to : always restrict access except for few classes.

The first thing I have I mind is the implementation of a Renderer.
You want it to be capable to access some RenderableObjects fields or functions that could not be accessed by other classes except the renderer.
Thus what was under the hood is kept under the hood.
Hey I may be wrong, and it may be done with an interface (?) (Really I'd be happy to learn).

Ben

On Sun, Nov 6, 2011 at 2:04 PM, Mihail Ivanchev <[hidden email]> wrote:
Friend class concept violates basic principles of OO design and encapsulation. Clearly, a private variable is part of the internal state of an object and no other object should access that. When you use friendly classes you say "I have a private var which is not really private, because someone else than I has access" which is in effect an oxymoron. 99,99% of the cases you use friendly variables you have a very bad and wrong design of in your architecture. Almost all cases of apparatent friendship relations are solved by giving the user an external interface / class:

interface IInterface
{
      function allowedOperation();
}

implementing that interface privately so that other internal code can communicate with your internal representation (your "relationship"):

class InternalRepresentation implements IInterface
{
     function someFunctionThatInternalCodeCanCallInsteadOfFriendlyFields()
     {
     }
}

and you return InternalRepresentation to the outside world.

Do not ruin good design for simplicity, ever.

Regards,
Mihail

On Sun, Nov 6, 2011 at 1:13 PM, benjamin Dubois <[hidden email]> wrote:
Mikael, I don't understand why friend class concept being lazy and dangerous (maybe you can enlighten me), neither why factory are better patterns, and last I don't even understand how your example work.

Friend class is an easy concept to grasp.
I'm no monster programmer, but keeping thing simple are IMO the best way to maintain your code.

btw +1 for the friend keyword since it really looks like it behaves like the cpp friend concept.

Ben

On Sun, Nov 6, 2011 at 11:42 AM, [hidden email] <[hidden email]> wrote:
if I import the class I would expect not to put a full qualified class path.  If two classes could be possible I would want it to infer the correct type.

for example with the adding keyboard listeners from awhile back I had two classes that I could 'using' one for Int, and one for Strings( letters ) that I could get to easily wire up the key stroke events.  If these were private static functions... I would want the function that I had given access to, to be able to infer the correct type even though this is being setup by a macro... this is why I wonder if macro is possible/suitable or if this needs to be deeper in haXe?

I think 'access' is not ideal since we talk about giving access or having access, the concept of taking access seems like freedom of information act in the uk so maybe free would work, but 'take' does not sound good.  For clarity I suggest a few alternatives appended with Access.

@:giveAccess( SecretService )
@:freeAccess( Secrets )

@:giveAccess( SecretService)
@:permitAccess(Secrets )

@:giveAccess( SecretService)
@:haveAccess( Secrets )

I think maybe the more verbose style I suggest, will make it easier for new users?

Or maybe a system where you can setup the access type from a single macro

@:Access( SecretService, Give );
@:Access( Secret, Have );
@:Access( Secrets, TwoWay );

@:Access( SecretService, OUT );
@:Access( Secret, IN );
@:Access( Secrets, BOTH );




On 6 Nov 2011, at 08:59, Nicolas Cannasse wrote:

Hi,

Following recent discussions about the way you should be away to access other classes private variables and methods, I've written a draft about a new proposed feature called "Access Control" :

http://haxe.org/manual/acl

Thank you for your feedback, especially about the naming choice of @:give/@:access which I'm not 100% happy with, but it's not very easy to find better (please prove me wrong).

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


--
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: Private access control (draft)

Ian Martins
In reply to this post by Mihail Ivanchev
I think this would be good for writing unit tests of private methods.

-Ian

On Sun, Nov 6, 2011 at 8:04 AM, Mihail Ivanchev <[hidden email]> wrote:
Friend class concept violates basic principles of OO design and encapsulation. Clearly, a private variable is part of the internal state of an object and no other object should access that. When you use friendly classes you say "I have a private var which is not really private, because someone else than I has access" which is in effect an oxymoron. 99,99% of the cases you use friendly variables you have a very bad and wrong design of in your architecture. Almost all cases of apparatent friendship relations are solved by giving the user an external interface / class:

interface IInterface
{
      function allowedOperation();
}

implementing that interface privately so that other internal code can communicate with your internal representation (your "relationship"):

class InternalRepresentation implements IInterface
{
     function someFunctionThatInternalCodeCanCallInsteadOfFriendlyFields()
     {
     }
}

and you return InternalRepresentation to the outside world.

Do not ruin good design for simplicity, ever.

Regards,
Mihail

On Sun, Nov 6, 2011 at 1:13 PM, benjamin Dubois <[hidden email]> wrote:
Mikael, I don't understand why friend class concept being lazy and dangerous (maybe you can enlighten me), neither why factory are better patterns, and last I don't even understand how your example work.

Friend class is an easy concept to grasp.
I'm no monster programmer, but keeping thing simple are IMO the best way to maintain your code.

btw +1 for the friend keyword since it really looks like it behaves like the cpp friend concept.

Ben

On Sun, Nov 6, 2011 at 11:42 AM, [hidden email] <[hidden email]> wrote:
if I import the class I would expect not to put a full qualified class path.  If two classes could be possible I would want it to infer the correct type.

for example with the adding keyboard listeners from awhile back I had two classes that I could 'using' one for Int, and one for Strings( letters ) that I could get to easily wire up the key stroke events.  If these were private static functions... I would want the function that I had given access to, to be able to infer the correct type even though this is being setup by a macro... this is why I wonder if macro is possible/suitable or if this needs to be deeper in haXe?

I think 'access' is not ideal since we talk about giving access or having access, the concept of taking access seems like freedom of information act in the uk so maybe free would work, but 'take' does not sound good.  For clarity I suggest a few alternatives appended with Access.

@:giveAccess( SecretService )
@:freeAccess( Secrets )

@:giveAccess( SecretService)
@:permitAccess(Secrets )

@:giveAccess( SecretService)
@:haveAccess( Secrets )

I think maybe the more verbose style I suggest, will make it easier for new users?

Or maybe a system where you can setup the access type from a single macro

@:Access( SecretService, Give );
@:Access( Secret, Have );
@:Access( Secrets, TwoWay );

@:Access( SecretService, OUT );
@:Access( Secret, IN );
@:Access( Secrets, BOTH );




On 6 Nov 2011, at 08:59, Nicolas Cannasse wrote:

Hi,

Following recent discussions about the way you should be away to access other classes private variables and methods, I've written a draft about a new proposed feature called "Access Control" :

http://haxe.org/manual/acl

Thank you for your feedback, especially about the naming choice of @:give/@:access which I'm not 100% happy with, but it's not very easy to find better (please prove me wrong).

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


--
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: Private access control (draft)

laurence taylor
In reply to this post by Nicolas Cannasse
Well, it kind of is, but it's the principle that pairs of function names are nicer having the same length. get / set for example
Would crud be the appropriate metaphor, would it make sense for a class to be able to create an instance but not edit it? how about @edit and @read?



On Sun, Nov 6, 2011 at 10:20 AM, Nicolas Cannasse <[hidden email]> wrote:
Le 06/11/2011 10:10, Laurence Taylor a écrit :

@:give and @:take? It also happens to be an English idiom.

"giving access" seems natural to me but "taking access" seems a bit od. I'm not a native speaker.


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: Private access control (draft)

jlm@justinfront.net
In reply to this post by bubblebenj
Ok after some more thought, I have a new argument..... which maybe wrong but I will present it so that it can be considered, I don't believe there is a need for give and take... just take.

You should only take access, never give access, since if you limit it to one or the other then Take is the option that allows you to extend thirdparty classes where you need access to private functionality.  The issue I have with having 'give' and 'take' is that it is harder to check access and it can easily become confusing.  If the class/function calling a function is allowed to take access of a private then you only have to check one place.  But if you "give" then the class that your giving access to becomes linked to class that does not need to know, and then you have to modify the giver if you remove the taker later from your class structures maintenance could become a nightmare, the giver should not know or care who the takers are, but ideally the compiler should maybe let you know of private breaches - for instance so if you use a third party library that accesses say private functionality of the standard library then it would be good to know without checking a huge library that you may not totally understand but need to use for 3d or something.  So some warning file should maybe be generated with any private access being made.  I guess it's like using... you would not put who is using you, and like a listener you don't define who is listening to you, and you should not say who is taking from you.  But I can see that having takers defined in the giver is bad.

I propose 'give' is not implemented, then @Access is much clearer in its meaning since it only takes, and it will be a lot easier to minimize access.


Cheers
;j  

On 6 Nov 2011, at 12:42, benjamin Dubois wrote:

Also it's nice to be able to give friendship to a whole package :D

Ben
--
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: Private access control (draft)

jlm@justinfront.net
Actually this should not be a macro this should be like "using" and use the keyword "taking", then using could be refined to be able to be applied in more function/var way as well.


On 6 Nov 2011, at 14:12, [hidden email] wrote:

Ok after some more thought, I have a new argument..... which maybe wrong but I will present it so that it can be considered, I don't believe there is a need for give and take... just take.

You should only take access, never give access, since if you limit it to one or the other then Take is the option that allows you to extend thirdparty classes where you need access to private functionality.  The issue I have with having 'give' and 'take' is that it is harder to check access and it can easily become confusing.  If the class/function calling a function is allowed to take access of a private then you only have to check one place.  But if you "give" then the class that your giving access to becomes linked to class that does not need to know, and then you have to modify the giver if you remove the taker later from your class structures maintenance could become a nightmare, the giver should not know or care who the takers are, but ideally the compiler should maybe let you know of private breaches - for instance so if you use a third party library that accesses say private functionality of the standard library then it would be good to know without checking a huge library that you may not totally understand but need to use for 3d or something.  So some warning file should maybe be generated with any private access being made.  I guess it's like using... you would not put who is using you, and like a listener you don't define who is listening to you, and you should not say who is taking from you.  But I can see that having takers defined in the giver is bad.

I propose 'give' is not implemented, then @Access is much clearer in its meaning since it only takes, and it will be a lot easier to minimize access.


Cheers
;j  

On 6 Nov 2011, at 12:42, benjamin Dubois wrote:

Also it's nice to be able to give friendship to a whole package :D

Ben
--
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: Private access control (draft)

Mihail Ivanchev
In reply to this post by bubblebenj
I do not restrict access with the interface. Instead the interface is what the user will get and be able to manipulate. The implemenation of the interface is private and will not be accessible to the user so I can implement whatever pattern I wish to modify the inner state. For example the implementing class (because it's hidden) could provide PUBLIC methods for the rest of the internal implementation to modify it's state. Thus, the friendship is not needed anymore and the problem is resolved using standard OO practices. Friendship could be viewed as a shortcut that you use as an excuse not to finish the design of an architecture. An object should never allow anyone to modify it's inner state. Otherwise we cannot talk about OO anymore.

On Sun, Nov 6, 2011 at 2:43 PM, benjamin Dubois <[hidden email]> wrote:
I still don't get how you restrict access with interface.
OK you don't have access to the private field, but the problem is only transferred to implementation of the interface (not sure I'm clear).
You may still want to be capable to : always restrict access except for few classes.

The first thing I have I mind is the implementation of a Renderer.
You want it to be capable to access some RenderableObjects fields or functions that could not be accessed by other classes except the renderer.
Thus what was under the hood is kept under the hood.
Hey I may be wrong, and it may be done with an interface (?) (Really I'd be happy to learn).

Ben

On Sun, Nov 6, 2011 at 2:04 PM, Mihail Ivanchev <[hidden email]> wrote:
Friend class concept violates basic principles of OO design and encapsulation. Clearly, a private variable is part of the internal state of an object and no other object should access that. When you use friendly classes you say "I have a private var which is not really private, because someone else than I has access" which is in effect an oxymoron. 99,99% of the cases you use friendly variables you have a very bad and wrong design of in your architecture. Almost all cases of apparatent friendship relations are solved by giving the user an external interface / class:

interface IInterface
{
      function allowedOperation();
}

implementing that interface privately so that other internal code can communicate with your internal representation (your "relationship"):

class InternalRepresentation implements IInterface
{
     function someFunctionThatInternalCodeCanCallInsteadOfFriendlyFields()
     {
     }
}

and you return InternalRepresentation to the outside world.

Do not ruin good design for simplicity, ever.

Regards,
Mihail

On Sun, Nov 6, 2011 at 1:13 PM, benjamin Dubois <[hidden email]> wrote:
Mikael, I don't understand why friend class concept being lazy and dangerous (maybe you can enlighten me), neither why factory are better patterns, and last I don't even understand how your example work.

Friend class is an easy concept to grasp.
I'm no monster programmer, but keeping thing simple are IMO the best way to maintain your code.

btw +1 for the friend keyword since it really looks like it behaves like the cpp friend concept.

Ben

On Sun, Nov 6, 2011 at 11:42 AM, [hidden email] <[hidden email]> wrote:
if I import the class I would expect not to put a full qualified class path.  If two classes could be possible I would want it to infer the correct type.

for example with the adding keyboard listeners from awhile back I had two classes that I could 'using' one for Int, and one for Strings( letters ) that I could get to easily wire up the key stroke events.  If these were private static functions... I would want the function that I had given access to, to be able to infer the correct type even though this is being setup by a macro... this is why I wonder if macro is possible/suitable or if this needs to be deeper in haXe?

I think 'access' is not ideal since we talk about giving access or having access, the concept of taking access seems like freedom of information act in the uk so maybe free would work, but 'take' does not sound good.  For clarity I suggest a few alternatives appended with Access.

@:giveAccess( SecretService )
@:freeAccess( Secrets )

@:giveAccess( SecretService)
@:permitAccess(Secrets )

@:giveAccess( SecretService)
@:haveAccess( Secrets )

I think maybe the more verbose style I suggest, will make it easier for new users?

Or maybe a system where you can setup the access type from a single macro

@:Access( SecretService, Give );
@:Access( Secret, Have );
@:Access( Secrets, TwoWay );

@:Access( SecretService, OUT );
@:Access( Secret, IN );
@:Access( Secrets, BOTH );




On 6 Nov 2011, at 08:59, Nicolas Cannasse wrote:

Hi,

Following recent discussions about the way you should be away to access other classes private variables and methods, I've written a draft about a new proposed feature called "Access Control" :

http://haxe.org/manual/acl

Thank you for your feedback, especially about the naming choice of @:give/@:access which I'm not 100% happy with, but it's not very easy to find better (please prove me wrong).

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


--
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: Private access control (draft)

Gamehaxe
In reply to this post by Nicolas Cannasse
Hi,
I like the framework.
I think "grant access" is slightly more correct than "give access",
and possibly reads slightly better with the package nouns.
If it were "control" then I think "assume control" would convey the
meaning of forcing your will on the control - not so sure about "assume  
access"
Perhaps "hijack" would convey a suitably dangerous activity? : grant/hijack

Another pair that may be easy to remember:  trust/trustedBy
Implies that either party can declare their trust.

Hugh



> Le 06/11/2011 10:10, Laurence Taylor a écrit :
>> @:give and @:take? It also happens to be an English idiom.
>
> "giving access" seems natural to me but "taking access" seems a bit od.  
> I'm not a native speaker.
>
> Best,
> Nicolas

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

Re: Private access control (draft)

danielku15
In reply to this post by Nicolas Cannasse
Hi Nicolas.

Sounds great, glad to see that haXe becomes more suitable for library development :D

I'm missing a general concept which is not available yet. Currently it's all about opening up and give/take access to members even more. What about restricting access to members? Currently real private members cannot be declared which gives access to internal modules.

What about a @:restrict like construct to restrict the access to a 'private' level. A parameter could look like this: @:restrict(my.pack) which means "don't allow access from members which are not in this package".

Another problem using this extended macro approach: Most languages do not have a feature like "friend" classes. Does that mean if I declare a method private and any @:give, @:take, @:access is set to a member, it becomes public and the compiler does the rest checking?

I'm also in fear of the @:access approach. Isn't it all about restricting rather than opening in OOP (encapsulation)? @:access(my.secure.LicenseSystem.unlockEverything) allows everyone to use internal secret methods which are not designed to become public.

A 2 way contract would be a more secure way: The class providing a private method, should make it accessible via @:give, and the other method should gain access via @:access. @:access to an element not marked with @:give will not work.

Yesterday I started working on a C# code generator using macros and encountered a lot of problems against visibility. Currently all private members are 'protected virtual'. For a C# library/application that's quite bad design. Additionally stuff like friend classes are not available in C#.

What are the plans how the resulted code will look like?

Greetings Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Private access control (draft)

singmajesty
In reply to this post by Nicolas Cannasse
Hey Nicolas,

I really like this approach.

What do you think about using a keyword other than "give"?



@:allow (com.eclecticdesignstudio) private var myProperty:Dynamic;


@:public (com.eclecticdesignstudio) private var myProperty:Dynamic;



On Sun, 06 Nov 2011 01:59:38 -0700, Nicolas Cannasse  
<[hidden email]> wrote:

> Hi,
>
> Following recent discussions about the way you should be away to access  
> other classes private variables and methods, I've written a draft about  
> a new proposed feature called "Access Control" :
>
> http://haxe.org/manual/acl
>
> Thank you for your feedback, especially about the naming choice of  
> @:give/@:access which I'm not 100% happy with, but it's not very easy to  
> find better (please prove me wrong).
>
> Best,
> Nicolas
>


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

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

Re: Private access control (draft)

Juraj Kirchheim
In reply to this post by danielku15
Hi Nicolas,

as I said earlier, IMHO having to actually use this feature is a code smell.

The question I have is: will this work with interfaces?
Can I say:

        interface IFoo {
                @:give(foo) function darkFooMagic():Void;
        }
        class Foo implements IFoo {
                @:give(foo) function darkFooMagic():Void;
        }

And the compiler enforces that darkFooMagic has at least @:give(foo)
access (but public should also be ok).

Plus, I am wondering how this will be represented at macro-time.
Because having this just somewhere in the meta-data doesn't seem
right, while at the same time I wouldn't want to treat this as an
extra case.

Personally, I think this will overcomplicate things. A lot of people
will be using this instead of just creating a clean type hierarchy.
Accessing something that isn't public is a hack. No matter how pretty
a system you use for it.

As I said, the weird thing about private structures is simply, that
it's not evident and that it kind of overloads the meaning of field
access control (because private usually means "can't touch this" but
suddenly changes its meaning to "can touch this, even if it's actually
forbidden").
I think the solution you are proposing now overshoots the mark and
substitutes a slightly quirky yet weirdly elegant system with a
"dangerously powerful" one. Splitting the choice between public and
private at the declaration site with a arbitrarily distinctive choice
at both declaration and callsite seems like a big deal to me.

It's almost irrelevant how the tags are named. The key questions are:
- Do we need such a system?
- Will this work well with all other language features?
- Isn't such a system promoting poor coding practices?

IMHO allowing something like private(someInstance.privateField) or
$private(someInstance.privateField) or someInstance.$privateField
seems dead simple to me, and good enough. And technically it doesn't
really require new syntax. Nor a complex system that complicates
access control.

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