Being able to proxy to another object is such an important feature,
that even in ES6 (aka "Javascript") there is a Proxy object [1] that
allows you to intercept/redefine operations for that object.
In the case of Smalltalk, and coming back to the original topic of
this thread, that is even more
This has been an interesting thread to read on the side, and I appreciate the
thought provoking conversion.
On Sun, 20 Mar 2022, at 6:11 AM, Richard O'Keefe wrote:
> An override of #doesNotUnderstand: *is* (an instance of) the problem.
> What part of "you may think you know what to forward now,
Richard,
My primary reference for the Proxy Pattern is the classic "Design Patterns,
Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson, and
Vlissides (Addison-Wesley 1995). In describing how to implement the pattern the
“Gang of Four (or GOF)" advise “using
Never forget that the Proxy pattern was developed in the context of a TYPED
programming
language. So "Clients can't tell whether they work with a subject or its
proxy” means WITH REFERENCE
TO A STATED PROTOCOL. Doing this in Ada or Java is fine, because you
define an interface type, and that
Hello Richard,
> What part of … is hard to understand?
Did you mean for this to come off as condescending? Or are you are honestly
wondering how effectively you are communicating? In either case, all of it is
hard for me to understand since it doesn’t describe the Proxy Pattern which
requires
An override of #doesNotUnderstand: *is* (an instance of) the problem.
What part of "you may think you know what to forward now, but just
wait a couple of months or install an additional package and there
will be *more* selectors you needed to think about but didn't" is
hard to understand?
Proxies
I don’t understand. Wouldn’t an override of #'doesNotUnderstand:’ solve this
problem? The proxies I’ve seen subclass from nil or ProtoObject and forward
almost everything to the target. It’s really very easy.
> On Mar 19, 2022, at 3:14 AM, Richard O'Keefe wrote:
>
> An object should be a
An object should be a Proxy or Stub only with reference to a specific
protocol, which should be kept narrow.
Being a Proxy is a form of coupling. Proxying a wide
interface creates maintenance problems:
Squeak 5.3 : Object selectors size => 485
Pharo 9.0 : Object selectors size => 435
astc
> On Mar 18, 2022, at 11:39 AM, Esteban Maringolo wrote:
>
> You say that Smalltalk is not so hot for system developments because
> it's extremely malleable? What are you measuring it against?
Lots of things but to keep things simple lets go with Objective C since it is
quite similar in
On Fri, Mar 18, 2022 at 3:24 PM Todd Blanchard via Pharo-users
wrote:
>
> What, exactly, is inconsistent about a key message isNil being allowed to be
> overridden?
Overrides are not the issue here.
> There is a VERY simple solution to your problem that does not involve
> disrupting the
What, exactly, is inconsistent about a key message isNil being allowed to be
overridden?
There is a VERY simple solution to your problem that does not involve
disrupting the platform.
But you'd rather change the platform.
Part of the reason Smalltalk has not been the greatest platform to
> I feel like you’ve latched onto something that is genuinely a non problem…
I wouldn’t call complexity and lack of consistency a “non problem”, but it
sounds like for you the practical implications outweigh my
seemingly-somewhat-ideological/niche concerns. Is that a fair summary? In any
case,
I feel like you’ve latched onto something that is genuinely a non problem and
if you get your way we all suffer reduced performance and a guarantee that a
nil test is universally the same thing.
If you want an overridable nil test, write your own nil test like isNilish and
make it mean what
> What you can do is turning it off globally in the setting (all compiler
> option are listed there)
>
> But take care: we can not recompile the image without optimzations as this
> adds intererrupt possibilities to code that was not
> interruptable before, which breaks the code in for process
> My chief concern is that I am a bear of very little brain,
> and if you change the meaning of #isNil to anything at all
> other than "is the receiver identical to nil" you *WILL*
> (not may) confuse me.
I can understand your probably well-justified concern that power can always be
misused. I
> My *concern* with inlining is that since it is designed to short-circuit
> dynamic method lookup, it is impossible to call a *different* implementation.
> That is, you lose the opportunity to have the *receiver* decide how to
> respond to the message. You may think of it as a message, but the
> On 17 Mar 2022, at 18:00, Esteban Maringolo wrote:
>
> That is great!
>
> Is it possible to disable it for doits and other playground expressions?
>
No, there is no hook yet… it would be interesting to see how to do that.
(e.g. per playground compiler parameters, parameters for doit
That is great!
Is it possible to disable it for doits and other playground expressions?
Regards!
Esteban A. Maringolo
On Thu, Mar 17, 2022 at 1:23 PM Marcus Denker wrote:
> On 17 Mar 2022, at 17:17, Richard Sargent
> wrote:
> A pragma might be the way to go.
> for example.
>
>
>
> There is
> On 17 Mar 2022, at 17:17, Richard Sargent
> wrote:
>
> A pragma might be the way to go.
>
> for example.
There is already the #compilerOptions: Pragma, e.g.:
For example this method compiled the and: as a real send:
tt
true and: [ false ]
>
> On Thu, Mar 17,
A pragma might be the way to go.
** for example.
On Thu, Mar 17, 2022 at 8:17 AM Esteban Maringolo
wrote:
> Just to add another argument in favor of not inlining some message
> sends, is for instance in things like Glorp you need to use a special
> selector for #and:/#or: message sends,
Just to add another argument in favor of not inlining some message
sends, is for instance in things like Glorp you need to use a special
selector for #and:/#or: message sends, breaking not only the naming
conventions but also the polymorphism.
E.g. you have to use #AND: and #OR: to avoid
Richard,
I very much admire Dijkstra’s admonition regarding “The Humble Programmer” and
was pointing a student to that article just this week.
In any case, I think you’ve demonstrated that you now comprehend the argument
against inlining—you just don’t agree. That’s fair and I think the
My chief concern is that I am a bear of very little brain,
and if you change the meaning of #isNil to anything at all
other than "is the receiver identical to nil" you *WILL*
(not may) confuse me. This extends to things that happen
not to be inlined: if even a god-like Smalltalker like
Andres
Sean
When the compiler inlines some methods, I would find it most surprising if it
was turned of in half the code (or just in yours :-) ). When I am reading some
code, I would rather have some consistency.
So I would just implement a whenNil: method which is a true message, and put a
comment
Richard,
My _concern_ with inlining is that since it is designed to short-circuit
dynamic method lookup, it is impossible to call a _different_ implementation.
That is, you lose the opportunity to have the _receiver_ decide how to respond
to the message. You may think of it as a message, but
We're still not on the same page.
You seem to have some ideological objection to inlining that
I am completely failing to comprehend.
Just because a procedure call (message send) is inlined doesn't
in the least mean it *isn't* a procedure call (message send),
just as compiling a procedure call
it's impossible to talk about a project that i don't understand.
this sentence
*In the second code especially, the problem is that `position` could be
many types that are not in the same hierarchy,*
draw my attention, because i did many hierarchies when you don't need to
do it. just use
On 3/16/2022 8:33 PM, s...@clipperadams.com wrote:
I care because it makes “everything is a message” a lie! And I suspect
(no proof and could be wrong) it’s an optimization that only made
sense with the hardware constraints of 40+ years ago. Arguing against
premature optimization is hardly
> if you are using the null object pattern then you should not write those
> checks (ifNil:ifNotNil:, isNil, isNotNil). you should send the message to
> an instance of the null object and that object should decide what to do.
> just an opinion.
I agree as a general rule, but it can get
> To start with, why do you CARE whether a particular
> method is inlined or not?
I care because it makes “everything is a message” a lie! And I suspect (no
proof and could be wrong) it’s an optimization that only made sense with the
hardware constraints of 40+ years ago. Arguing against
if you are using the null object pattern then you should not write those
checks (ifNil:ifNotNil:, isNil, isNotNil). you should send the message to
an instance of the null object and that object should decide what to do.
just an opinion.
On Tue, Mar 15, 2022 at 3:16 PM wrote:
> I had some
Why do you not just do something like
[ “complicated code that might fail somewhere in here” ]
on: Error
do: [:error | nil]
Use the on:do: exception handling to stay safe.
Result := [anObject long chain of messages that might return a nilValue ]
on: Error do: [:e |
I have a bad feeling about this.
To start with, why do you CARE whether a particular
method is inlined or not?
However, I’m struggling a bit with the refactor due to inlining. Since
#ifNil: variants might be inlined, it seems that something like:
anObject with a long chain of messages ifNotNil:
+1
Inlining breaks the fundamental piece of OOP: Message sends.
I'm sure there are use cases where inlining adds a significant
speedup, but for some messages, I prefer them to be sent.
Regards!
Esteban A. Maringolo
On Tue, Mar 15, 2022 at 3:16 PM wrote:
>
> I had some chaining that was
34 matches
Mail list logo
