Privates and their 'true' meaning 
Author Message
 Privates and their 'true' meaning

In some languages that use 'private', private is use to limit
access.  However, 'private' in VW is used simply as a protocol
and doesn't directly limit access.

Is there any understanding behind the messages that are set in a
protocol of 'private'???  I am mainly speaking to the 'delivered'
functionality
from VW.  Is it marked private because, it could change or go away in
a future release?  Some of this stuff I would like to use but I certainly do
not
want to be using functionality that might not be there in the future.

thanks,
Craig.



Thu, 02 Sep 2004 04:31:13 GMT  
 Privates and their 'true' meaning
Method placed in the private  category of a class should only be used by
method defined for that class.

Jan


Quote:
> In some languages that use 'private', private is use to limit
> access.  However, 'private' in VW is used simply as a protocol
> and doesn't directly limit access.

> Is there any understanding behind the messages that are set in a
> protocol of 'private'???  I am mainly speaking to the 'delivered'
> functionality
> from VW.  Is it marked private because, it could change or go away in
> a future release?  Some of this stuff I would like to use but I certainly
do
> not
> want to be using functionality that might not be there in the future.

> thanks,
> Craig.



Thu, 02 Sep 2004 07:09:17 GMT  
 Privates and their 'true' meaning


Quote:
> In some languages that use 'private', private is use to limit
> access.  However, 'private' in VW is used simply as a protocol
> and doesn't directly limit access.

> Is there any understanding behind the messages that are set in a
> protocol of 'private'???  I am mainly speaking to the 'delivered'
> functionality
> from VW.  Is it marked private because, it could change or go away in
> a future release?  Some of this stuff I would like to use but I
> certainly do not
> want to be using functionality that might not be there in the future.

That is why it is marked as private.

However, one reason private is not enforced is that
we don't do a good job of predicting what others
need and what the future will bring.  This allows
you to use a private method, but at your own risk.

You can also add your own method to the class and
use it.  This is referred to as an extension.

Quote:
> thanks,
> Craig.

--
Terry
===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
80 Lazywood Ln.                  VW and ENVY/Developer
Tiverton, RI  02878

http://www.craftedsmalltalk.com
===========================================================


Thu, 02 Sep 2004 18:13:04 GMT  
 Privates and their 'true' meaning
BTW, not every Smalltalk dialect offers a "private" category.
What do the standards (ANSI) say about private methods? Are they even
mentioned?


Thu, 02 Sep 2004 16:37:16 GMT  
 Privates and their 'true' meaning
Hi Craig,

Your interpretation is correct. Methods in 'private' protocols are subject
to change or disappearence. But the use of 'private' as not intended for use
by other classes' is also legitimate.

Ivan


Quote:
> In some languages that use 'private', private is use to limit
> access.  However, 'private' in VW is used simply as a protocol
> and doesn't directly limit access.

> Is there any understanding behind the messages that are set in a
> protocol of 'private'???  I am mainly speaking to the 'delivered'
> functionality
> from VW.  Is it marked private because, it could change or go away in
> a future release?  Some of this stuff I would like to use but I certainly
do
> not
> want to be using functionality that might not be there in the future.

> thanks,
> Craig.



Thu, 02 Sep 2004 20:46:06 GMT  
 Privates and their 'true' meaning

Quote:

> Method placed in the private  category of a class should only be used by
> method defined for that class.

There are many meanings of "private", that is just one of them.

A better formulation (I think) is that the method is not part of the
published contract provided by that object.

I think that captures *most* of the meanings that people use for "private".

    -- chris



Thu, 02 Sep 2004 20:01:08 GMT  
 Privates and their 'true' meaning

Quote:

> What do the standards (ANSI) say about private methods? Are they even
> mentioned?

No.

    -- chris



Thu, 02 Sep 2004 19:59:15 GMT  
 Privates and their 'true' meaning
Anything in a "private" category is not guaranteed to be there in future
releases.  In other words it means, "use me at your own risk."  I always
think of Smalltalk as a "gentleman's" language, therefore, we don't enforce
things like public, private interfaces.  However, we do want to reserve the
right to make changes to our objects, so by putting it in the private
category, we are giving fair warning of our intent.
Regards,
Gary

Quote:
> In some languages that use 'private', private is use to limit
> access.  However, 'private' in VW is used simply as a protocol
> and doesn't directly limit access.

> Is there any understanding behind the messages that are set in a
> protocol of 'private'???  I am mainly speaking to the 'delivered'
> functionality
> from VW.  Is it marked private because, it could change or go away in
> a future release?  Some of this stuff I would like to use but I certainly
do
> not
> want to be using functionality that might not be there in the future.

> thanks,
> Craig.



Fri, 03 Sep 2004 10:24:50 GMT  
 Privates and their 'true' meaning

Quote:

> In some languages that use 'private', private is use to limit
> access.  However, 'private' in VW is used simply as a protocol
> and doesn't directly limit access.

> Is there any understanding behind the messages that are set in a
> protocol of 'private'???  I am mainly speaking to the 'delivered'
> functionality
> from VW.  Is it marked private because, it could change or go away in
> a future release?  Some of this stuff I would like to use but I certainly do
> not
> want to be using functionality that might not be there in the future.

> thanks,
> Craig.

Everyone is way too calm about this.  Let me try: Enforced privacy
gradations are one of the most useless can of worms that sneaks into a
language design.

The designations you have are never enough -- it starts out with
public and private, and then someone adds protected, and then private
protected...  How many designations does C++ have, and is it really
enough?  Protection levels in a real program are more complicated than
the naive public/private leads people to expect, and so you end up
with very complex systems, or--in practice--simplistic systems that
can't encode the true protection levels.

Furthermore, protection levels are not what the programmer is mainly
thinking about, unless they have too much time.  The programmer is
trying to get a job done, and the protection levels are tossed in on
the side.  How likely are the protection levels to be well designed
and correct?  Pretty slim!  Whatever value static protection levels
give a program, is greatly reduced by their slipshod quality.  Anyone
who thinks *their* protection levels are correct, please consider: how
often are they put to the test?

And finally, consider what the effort is oriented towards: protecting
programmers from themselves.  This is always a dangerous stance to
take, anyway, and in the case of protection levels the danger seems to
be real.  How often do you recall thinking, "Oh good, the compiler
won't let me call this method.  Phew!  Thank you compiler!  I sure
came close to screwing up there!"  Much more common, in my little
experience with languages like this, are thoughts like "That method is
private?!  Hmm, suddenly this one-liner isn't a one-liner...."

Static protection levels are like static typing, but with less benefit.

-Lex



Fri, 03 Sep 2004 12:55:24 GMT  
 Privates and their 'true' meaning
Ain't that the truth!  The problem in my mind is that words like "private"
and "protected" implies that it provides some mechanism of safety for a
problem that does not exist.  In Smalltalk seeing that a method is private
is a nice marker to indicate that for whatever reason one should not count
on it always existing or behaving exactly as it does now.

What would be even better is if we could have more control over coding
constraints.  I would love to be able to dynamically attach attributes to
methods based on system-specific information.  For instance, I might like
to attach some kind of dependency on a method that will cause a message
get written to the Transcript as soon as someone tries to overload it.  A
message like, "Overloading method Object>>= ... remember to overload #hash
appropriately as well," would be quite helpful for some people.  Another
possibility is marking methods that should be implemented so that when one
makes a new subclass of it the system will auto-generate methods that
should be implemented ... maybe containing nothing but a notYetImplemented
message.

Wouldn't it be nice to counter the proponents of the
public/private/protected constraints with something that is truly more
useful?

Just a few thoughts,
Jon


...cut...

Quote:
> The designations you have are never enough -- it starts out with public
> and private, and then someone adds protected, and then private
> protected...  How many designations does C++ have, and is it really
> enough?  Protection levels in a real program are more complicated than
> the naive public/private leads people to expect, and so you end up with
> very complex systems, or--in practice--simplistic systems that can't
> encode the true protection levels.

...cut...


Sat, 04 Sep 2004 12:51:01 GMT  
 Privates and their 'true' meaning

Quote:

> What would be even better is if we could have more control over coding
> constraints.  I would love to be able to dynamically attach attributes to
> methods based on system-specific information.

What's preventing you from doing that ?

At least in Dolphin there are enough events triggered by the system that you
can hang off them and take whatever actions you see fit.

For some time now, I've been considering hacking together an enhancement
(well *I* think it would be an enhancement ;-) to the system that would
watch for class/method definition changes and maintain various kinds of
relationship between the classes.  E.g. in Dolphin there are Arrays and
ExternalArrays; they have very different implementations, and do not inherit
from each other, but they are intended to be polymorphic, so it'd be nice if
any little utility methods added to Array (or a superclass) were
automatically propagated to ExternalArray too.  One can come up with many
other examples (such as the ones you mentioned).

So far, it's just vapourware, though.

    -- chris



Sun, 05 Sep 2004 19:19:47 GMT  
 Privates and their 'true' meaning

Quote:

> > What would be even better is if we could have more control over coding
> > constraints.  I would love to be able to dynamically attach attributes
to
> > methods based on system-specific information.

> What's preventing you from doing that ?

> At least in Dolphin there are enough events triggered by the system that
you
> can hang off them and take whatever actions you see fit.

> For some time now, I've been considering hacking together an enhancement
> (well *I* think it would be an enhancement ;-) to the system that would
> watch for class/method definition changes and maintain various kinds of
> relationship between the classes.  E.g. in Dolphin there are Arrays and
> ExternalArrays; they have very different implementations, and do not
inherit
> from each other, but they are intended to be polymorphic, so it'd be nice
if
> any little utility methods added to Array (or a superclass) were
> automatically propagated to ExternalArray too.  One can come up with many
> other examples (such as the ones you mentioned).

What you are describing is a desire for Mixin/Interface behavior. Where the
behavior that is common to both can be declared in one place and shared by
multiple implementors. This is provided by the Mixin/Interface facilities of
SmallScript.

SmallScript also happens to provide the ability to add arbitrary
metadata/properties to any object at any time. So you can also provide
characteristics to any object as desired by Jon Anderson's comments.

Finally, SmallScript also supports managed objects which allows any object
to become the "manager" of any other object. This feature can be turned
on/off at any time. A manager has complete control over all messages and
read/write control over all slot and struct accesses. I.e., you can
proxy/control or provide full AOP control over any object at any time. Which
can be useful for debugging or simply spying on a given object. These
features are, of necessity, a VM provided service and so they are very fast.
This is one of the capabilities that gave SmallScript's underlying VM
technology its name "Agents Object System" (aka AOS).

P.S., SmallScript's selector namespace system also provides a much more
general/clean OO dynamic language equivalent to the statically constrained
and limiting notions of public/private/protected+friends. I.e., Selector
namespaces are units of (binding/message-access) priviledge.

-- Dave S. [www.smallscript.org]

- Show quoted text -

Quote:

> So far, it's just vapourware, though.

>     -- chris



Mon, 06 Sep 2004 04:19:31 GMT  
 Privates and their 'true' meaning
David,

Quote:
> What you are describing is a desire for Mixin/Interface behavior. Where
the
> behavior that is common to both can be declared in one place and shared by
> multiple implementors. This is provided by the Mixin/Interface facilities
of
> SmallScript.

Not exactly.  Yes, what I described *as one example* of what such a tool
could do, could also (more cleanly, I agree) by attacked with a mixin
approach.  The mechanistic (as opposed to semantic) approach can handle
other cases that mixins couldn't touch.  As an obvious example, it can
prompt me to ask if the proposed extension were appropriate for sharing with
other classes.  Another example (very Dolphin-specific), it could help
eliminate the tedium and potential inaccuracy of keeping the
#publishedEventsOfInstances methods up to date.

Actually I'm not sure this *particular* case could be well handled by
mixins; not with a Collection hierarchy which is essentially the same as the
ST80 one, anyway.  The problem being that any little utility methods that
have been added to or above Array (#any, say, or #mean) will have been added
to one of those rather concrete classes.  Unless the system is such that
Array could be used as a mixin class for ExternalArray (I've no idea whether
SmallScript would allow that, but it's not what I'd normally expect to be
able to do with a mixin system -- Array is too concrete) the Collection
hierarchy would need to be refactored quite extensively first.  (Not a bad
thing, IMO, but I'm talking about a tool to help with  the actual current
state of the system I work with most days, rather than an ideal future.)

Mind you.  I not putting mixins down -- I'd like to be able to use them
myself.  I'm just saying that there is a large niche for mechanistic methods
of maintaining a code-base's coherency to complement the traditional
semantic approaches.  The RB can be seen as another example of just that.

Quote:
> SmallScript also happens to provide the ability to add arbitrary
> metadata/properties to any object at any time. So you can also provide
> characteristics to any object as desired by Jon Anderson's comments.

Well, any language with weakly keyed dictionaries can do it too.  This
particular application doesn't need the optimised form.  What's much more
important is that the vendor-supplied tools (class builder, compiler,
whatever) generate the appropriate change noifications, or otherwise have
adequate hooks.  As it happens the Dolphin IDE (which applies the Observer
pattern rather thoroughly) does generate the necessary hooks.  So the rest
is easy.

Quote:
> Finally, SmallScript also supports managed objects which allows any object
> to become the "manager" of any other object. This feature can be turned
> on/off at any time. A manager has complete control over all messages and
> read/write control over all slot and struct accesses.

Yes, it's these kinds of improvements to the object model that I find
interesting and desirable in SmallScript.  In fact, they are why I haven't
just written it off as irrelevant (to me), since the syntax extensions (as
you may have gathered) are anathema, and I don't have any particular
requirement (as it happens) for cross-language work.

Quote:
> -- Dave S. [www.smallscript.org]

    -- chris


Wed, 08 Sep 2004 02:06:04 GMT  
 Privates and their 'true' meaning

Quote:
> David,

> > What you are describing is a desire for Mixin/Interface behavior. Where
> the
> > behavior that is common to both can be declared in one place and shared
by
> > multiple implementors. This is provided by the Mixin/Interface
facilities
> of
> > SmallScript.

> Not exactly.  Yes, what I described *as one example* of what such a tool
> could do, could also (more cleanly, I agree) by attacked with a mixin
> approach.  The mechanistic (as opposed to semantic) approach can handle
> other cases that mixins couldn't touch.  As an obvious example, it can
> prompt me to ask if the proposed extension were appropriate for sharing
with
> other classes.  Another example (very Dolphin-specific), it could help
> eliminate the tedium and potential inaccuracy of keeping the
> #publishedEventsOfInstances methods up to date.

Ironically, this exact feature is provided as a part of the object model's
basic property system [actually the dynamic event binding mechanism layered
upon it]. But, that is another discussion and would involve explaining
event-methods, property-fields, etc.

Quote:

> Actually I'm not sure this *particular* case could be well handled by
> mixins; not with a Collection hierarchy which is essentially the same as
the
> ST80 one, anyway.  The problem being that any little utility methods that
> have been added to or above Array (#any, say, or #mean) will have been
added
> to one of those rather concrete classes.  Unless the system is such that
> Array could be used as a mixin class for ExternalArray (I've no idea
whether
> SmallScript would allow that, but it's not what I'd normally expect to be
> able to do with a mixin system -- Array is too concrete) the Collection
> hierarchy would need to be refactored quite extensively first.  (Not a bad
> thing, IMO, but I'm talking about a tool to help with  the actual current
> state of the system I work with most days, rather than an ideal future.)

SmallScript allows a number of declaration forms to "correct" type heirarchy
designs.

a) You can uninherit a method or interface. AKA a $blocking method.

b) You can define a method which is not inheritable by subclasses. AKA a
$non-inheritable method.

c) You can define a method which is only inherited/invokable from a concrete
interface instance. AKA a $interface-only method.

d) You can define a sandbox-thunk method which can be invoked from within a
sandbox for calling to methods outside a sandbox. AKA a $safe method.

etc.

An <Interface> is a "concrete" mixin and can have concrete fields. A
<PureMixin> is an abstract mixin and can only have behavior and virtual
fields. Both types of mixins can be use to compose a collection framework --
it is one of the tasks I eagerly look forward to once the toolset and other
commercial projects are in a ready-release form. One of the key *new* design
patterns for mixins is the use of virtual fields and virtual property
fields. I make heavy use of them in the mixins I've been building for the
GUI system and browser toolkit for SmallScript.

Quote:

> Mind you.  I not putting mixins down -- I'd like to be able to use them
> myself.  I'm just saying that there is a large niche for mechanistic
methods
> of maintaining a code-base's coherency to complement the traditional
> semantic approaches.  The RB can be seen as another example of just that.

No particular disagreement. Mechanistic approaches can always be done in an
environment that supports dynamic language operations and MOP reflection
services and schema migration. However, a mechanistic approach may well
require source code availability -- and that is simply not acceptable in a
componentize world, even if the mechanistic operation performance costs
were.

Quote:

> > SmallScript also happens to provide the ability to add arbitrary
> > metadata/properties to any object at any time. So you can also provide
> > characteristics to any object as desired by Jon Anderson's comments.

> Well, any language with weakly keyed dictionaries can do it too.  This
> particular application doesn't need the optimised form.  What's much more
> important is that the vendor-supplied tools (class builder, compiler,
> whatever) generate the appropriate change noifications, or otherwise have
> adequate hooks.  As it happens the Dolphin IDE (which applies the Observer
> pattern rather thoroughly) does generate the necessary hooks.  So the rest
> is easy.

Sure. But having it available on every object with intrinsic VM support
changes things dramatically.

Because:

a) now the performance costs for extensive use of such capabilities are not
the issue they otherwise would be.

b) the property mechanism is standardized. Thus one can integrate it into
the reflection facilities and browser tools. Different developers can make
non-conflicting changes or extrinsically examine each others work.

c) the module system can now incorporate and properties, and preserve the
metadata as part of the module generation. Which also means developers can
make arbitrary extensions to the MOP architecture.

etc.

Quote:

> > Finally, SmallScript also supports managed objects which allows any
object
> > to become the "manager" of any other object. This feature can be turned
> > on/off at any time. A manager has complete control over all messages and
> > read/write control over all slot and struct accesses.

> Yes, it's these kinds of improvements to the object model that I find
> interesting and desirable in SmallScript.  In fact, they are why I haven't
> just written it off as irrelevant (to me), since the syntax extensions (as
> you may have gathered) are anathema, and I don't have any particular
> requirement (as it happens) for cross-language work.

<g>...

-- Dave S. [www.smallscript.org]

- Show quoted text -

Quote:

> > -- Dave S. [www.smallscript.org]

>     -- chris



Wed, 08 Sep 2004 04:31:17 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. What means, e.g., ('';'/')"_

2. Problem with 'Privates' Re-visited

3. open 'no-exist' rescue true - idiom

4. float('nan')==1 -> True

5. Send true '\r' character with expect

6. Distutils doesn't like VPS's (virtual private servers)

7. What does 'spaghetti' mean

8. Sory I meant '/'

9. 'hello' == 'hello' answers true

10. 'hello' == 'hello' answers true

11. What means, e.g., ('';'/')"_ ?

12. Oops... I meant 'Chez SCHEME', not Chez 'C'

 

 
Powered by phpBB® Forum Software