Unfortunately
I am not as fluent in the Code Critic as I am in the simpler interfaces in
Dolphin Smalltalk, so I can't just bang something out in 5 minutes, but
it's fundamentally not hard.
On Thu, Jul 10, 2025 at 4:35 AM Marcus Denker
wrote:
>
>
> > On 9 Jul 2025, at 21:37
This is very cool to see. One note—I would personally not outright
deprecate #receiver, but leave a comment indicating that it is not
guaranteed to be set and why. There are plenty of cases where getting nil
as the receiver of a clean block is correct, or at least good enough—I
wouldn't want to eve
f* the class, itself an instance of
`Metaclass`.
On Fri, Jun 27, 2025 at 4:45 PM Aik-Siong Koh wrote:
> "nil did not understand #selector" is great.
>
> Similarly, "Instance of " can be replace by "a" as in
> "aObject did not understand #selector"
Yes, I've run into this before. I think the reasoning is that, if you do
not copy down the superclass implementation, this is not truly a
refactoring—it will change the behavior of a selector that was already
understood by the siblings. But I agree that in many cases, this change of
behavior is the
I think it's because nil *is* pretty special--this is the equivalent of a
NullPointerException or similar in other languages (even though in fact nil
is an object like any other, it *is* usually a different type of *semantic*
error on the part of the programmer than with any other class).
Undefined
Is there documentation of the intended behavior/reasoning behind the
semantic sort somewhere? I feel like I might often prefer the SizeSorter
behavior (if I'm understanding it correctly), but if that's going to be
removed, maybe I would take a look at the semantic sorter and see if I can
add some r
the Ctrl dot event does not
> even arrive at Pharo or the trigger
> - if the recursion is hit when printing an object (which is more common
> than you could imagine), opening the debugger could trigger a new recursion
> and never give back the control to the user
>
>
> S
>
>
I would add, you can refer to yourself as @me in the search field, so the
following link is the same for everyone:
https://github.com/pharo-project/pharo/issues/created_by/@me
You can also combine open issues and open/unmerged PRs into a single search
by deleting is:issue from the query, resultin
Interesting! I submitted a Phep a while back to implement a compile-time
literal syntax ##() as seen in Dolphin Smalltalk, with literal collections
like this as a major (though not exclusive) use-case. At the time I
couldn't think of a way to do better for arbitrary collections, but this is
a very
Seems reasonable to me. I was just wishing for such a thing for exactly the
reason you mention (keeping track of zeroes in large integer literals).
AFAICT you've done a pretty good job laying out the possible error
conditions. I think your option 1 makes sense—the error-prone-ness is the
sort of th
A bit of perspective on other approaches to this problem:
In Dolphin Smalltalk, the FFI mechanism uses #doesNotUnderstand: to
implement getters and setters on external structs, so it already has a
mechanism for ensuring they aren't flagged as unimplemented. In addition to
the standard ClassDescrip
Everything you say is true, but I don't consider it nearly as serious a
trap as you say, because I wouldn't generally expect a "user" (that is, a
developer not explicitly working on Pharo itself) to modify the #=/#hash
implementation of a system class (that is, one included in the base image
and in
e integration with OpalCompiler etc., but we can probably
break this into several parts (compiler vs. decompiler, other peripheral
things) if others are interested.
I look forward to hearing what everyone thinks!
Thank you,
Daniel Slomovits
13 matches
Mail list logo
