Re: Protected static members, abstract classes, object composition vs. subclassing

VK wrote:
> Richard Cornford wrote:
>> try {
>> var goodBoy = new myClass();
>> goodBoy.messenger('Hi!');
>> }
>> catch(e) {
>> alert(e.message);
>> }
>>
>> try {
>> goodBoy.messenger.call({utils:goodBoy.utils}, 'Hi xxx!');
>> goodBoy.utils.messenger('Hi yyy xxx!');
>> ({messenger:goodBoy.utils.messenger}).messenger('Hi mmm xxx!');
>> }
>> catch(e) {
>> alert(e.message);
>> }
>
> Actually... having read you post once again I'm missing the
> point of your exaltation.
>
> myClassUtils constructor is minded to be "protected" - not
> "private". These are all different categories (depending of
> course of the school).

Protected is public to some (selected) objects and private to others.
With different languages applying different criteria to deciding who can
see what, and when.

> For me

This will be good.

> "protected" means that I cannot obtain an instance of such
> class independently but only as a part of a super-imposed
> class (myClass in this case).

So nothing related to the meaning of the term in any programming
language?

> So I don't see how the use of goodBoy which is a legal
> instance of myClass may prove anything in the concern
> of the "protected" status.

Your protected method could be called with any object as its - this -
object. If the function were a getter it would get for any object, if a
setter it would set for any object, and if it acted it would act for any
object.

> "private" means that a particular member is accessible only
> to the privileged object members - in the most common case
> to public object members. So in the listed case we want to
> make myClass.utils.messenger() to be accessible only to members
> of myClass.

Well, the object design is stupidly elaborated for no reason, but if you
insist.

> It is more tricky because despite argument.callee.caller
> gives us the actual caller,

Or not, in ECMAScript, where no - caller - property is defined.

> we cannot simply ask to caller "Who's your master?"
> because the caller has no clue itself at that time

As there may be no caller it could not be asked anything. But otherwise
this is incoherent.

> ("incontinence of [this]")

This is another manifestations of your general misconception of
javascript. The - this - keyword has well-defined and constantly
implemented meaning, your problems with it stem from your not
understanding javascript and nothing else.

> But you can check against some caller's feature to see if
> it's a valid caller. I left the final solution open so the
> relevant block is commented out. The first idea would be to
> use Java's object id-stamping. Thus each new instance get's
> an unique ID and you stamp all members which this ID:

Unnecessary as objects have distinct identity that can be verified.

> this.foo = /*public*/ function() {};
> this.foo.oID = newID;
>
> this.bar = /*private*/ function() {};
> this.bar.oID = newID;

You silly sod. Verification with a shared secret, and then making the
secret a public property of the objects so that it is not secret at all.
What a waste of effort! If you cannot apply better analysis to the
problem than this you are wasting everyone's time commenting on the
subject at all (although that goes for the vast majority of your posts
anyway).

> and then later in bar:
>
> if (arguments.callee.caller.oID = (arguments.callee.oID) {
^ ^
An assignment operator instead of comparison and unbalanced parenthesise
making this a syntax error?

> // legal call
> }
> else {
> throw new Error("Attempt to access private member out of the object
> scope");
> }

OK. That is actually less effective than your first attempt (even if the
errors were corrected).

> I'm not saying this is a final solution

I don't know, if your problem is only convincing people who don't know
any better this will do as well as the first.

> and in any case it still doesn't guarantee a buletproof
> protection as I said in the original post.

No, it isn't. But the question is not whether you are incapable of
implementing an effective emulation of 'protected' (in some meaningful
sense of the term) in javascript (obviously that if far beyond you), but
rather whether it can be done.

Having determined whether or not it can be done it becomes possible to
give an informed consideration as to whether it should be done (would
the overheads and authoring effort be justified by the result?). But
holding up a sequence of hollow imitations of some form of 'protection'
do not contribute at all to an understanding of the subject.

Richard.


.

Relevant Pages

  • Re: ArrayList behavior
    ... > declared private with protected set/get methods. ... pattern defintion for Transfer Object: ... members in the Transfer Object are defined as public, ... If some protection is necessary, ...
    (comp.lang.java.programmer)
  • Re: "composite" classes?
    ... > Since I didn't specify visibility, the members above would be private by ... and the caller could do what he wanted with it. ...
    (comp.lang.cpp)
  • Re: adminCount schema attribute
    ... The term "protection" means that the group and its members are protected from changes when delegation has been configured on some OU that contains the group and/or its members. ... BLOG --> http://blogs.dirteam.com/blogs/jorge/default.aspx ... * This posting is provided "AS IS" with no warranties and confers no rights! ...
    (microsoft.public.windows.server.active_directory)
  • Re: News Release
    ... members of militias or volunteer corps forming part of such armed forces. ... customs of war. ... The present Convention shall apply to the persons referred to in Article ... the protection of the present Convention until such time as their status ...
    (comp.security.firewalls)
  • Re: Attn: Fran - Ref Military Lawyers
    ... Guantanamo are not eligible for Geneva Convention protection. ... about the eligibility for GC protection of armed men in civilian ... Members of the armed forces of a Party to the conflict as well as members ...
    (misc.rural)