You are very right - it hadn’t sunk in that a compiled method attribute would
give you what you want - but then we are back to an easily extendible browser …
which I think calypso actually is … hmm should be quite easily doable to get
all described here - and show private methods in a private
Hi,
Smalltalk should be readable - so I dislike the prefix approach like "_"
or "priv".
Pharo has a unified property API so one can annotate both: methods and
classes
(unfortunately not yet serialized into Tonel). It could be used to
depict a scope or other:
MyClass propertyAt: #scope
If something, I'd rather have _ as a prefix indicating a private
method, very much like Dart does.
But why use a "syntax" trick when it could be an attribute of the
CompiledMethod itself?
As for many private methods being a code smell... it could be, but it
depends, until you find the right
As many have described, I’ve seen this work reasonably well too - while I’ve
seen the pvt prefix convention, I’ve also seen _name used to - which I felt was
marginally better (it also means private methods get grouped at the top of the
“all list” and not alphabetically in the middle’ish (but
One of the claimed benefits of object-oriented programming is ENCAPSULATION.
The idea is that one of the ways a language helps you is by making some errors
difficult or impossible to express.
One of the things you need to understand an object is its INVARIANT.
For example, astc's SortedCollection
Public/Private is not just a category, it is also a declaration of
what is the interface of the object.
As I said, it's not critical, but I've been working with and without a
"native" private method, and I prefer working with them.
Namespacing is a different animal, and not as simple to implement
Please keep Pharo simple, why do you need private methods...you can include
then in a protocol named private...other language have it...yes...next
addition will be namespaces...other...I don't know...at last we have Java
El jue., 19 ago. 2021 9:00, Richard O'Keefe escribió:
> Many years ago
Many years ago there was a proposal in the Squeak mailing list about enforcing
a naming convention, "pvt", I implemented that in my Smalltalk system. The
compiler enforces the rule that pvt.[A-Z].* message can only be sent to
(self|super) (basicNew|basicNew: n|new|new: n|pvtNew: n)?
in a class
I found this useful when creating commercial frameworks for VAST. For
instance, in the printing framework, I used the idea of a turtle (from
turtlegraphics) to create pages. All the turtle commands - turn(50) etc - were
public but the code that actually created the printing code was all
As Esteban pointed out there are some dialects with proper support for
that. But the semantics is the same as in Pharo, you can still send these
messages.
It is more a warning to the programmer, and the browser shows you these
methods with a particular icon or has tabs so you can easily filter
Hi Noury,
In Dolphin Smalltalk and in IBM/VA Smalltalk, methods can be private,
it's a special attribute of the CompiledMethod, so the visibility
doesn't depend on a category name convention, and you can have both
public and private methods sharing a single category. I used that
attribute
Hi Esteban,
Which first "class attribute" are you referring to? Is it a pragma? Can you
provide an example please ?
Thanx
Noury
On Aug 17 2021, at 10:31 pm, Esteban Maringolo wrote:
> I don't understand the request?
>
> Wouldn't tagging methods as private (as a first class attribute, and
> not
I don't understand the request?
Wouldn't tagging methods as private (as a first class attribute, and
not only its category) be enough?
What you ask for seems to be a splitted method dictionary of some sort.
Having first class private methods would save you from autocomplete
selector "pollution"
13 matches
Mail list logo
