Hi Tim,
if you're looking for experiments, you may want to look for the already
existing (or past) experiments on alternative systems browsers.
There are a few floating around, and some of them already have an answer
for what you are considering (change the way class side and instance
side methods are shown). Since you're interested in GTInspector as well,
maybe adding GT extensions to a class could let you experiment on that.
Regards,
Thierry
Le 23/07/2017 à 17:04, Tim Mackinnon a écrit :
I think my thread is misunderstood - I’m not saying change how methods work,
class methods are fine, instance methods are fine - I’m just saying I don’t
think its ideal anymore to see them so separately in our UI. It was really
driven home watching great programmers struggle (sure Smalltalk is a bit
different - and there are many elegant things we have, but class methods are
pretty normal in many languages) - and I have a similar frustration in that I
find it a straight jacket that we have to click that class button just because
we want to write what is effectively a constructor that occurs to us when we
are writing an instance method. Its very jarring and breaks your flow to
“switch mode” to type one in.
I think Pharo is an environment to experiment with how we think about
programming (in Smalltalk as well as other languages) - GTInspector is
marvellous, that is something that really shows how thinking about the problem
differently can make such a difference. While, I think our standard code
browsers are ok - they are stuck in a rut that we need to break. Calypso is a
hint at what is possible, but I want GTinspector type thinking more prevalent…
with similar types of ideas that inspire us to code better.
Anyway, it seems like I need to take this away and try some experiments by
myself.
Tim
On 23 Jul 2017, at 12:45, Stephane Ducasse <stepharo.s...@gmail.com> wrote:
Hi subbu
I used the same metaphor :)
Stef
On Sat, Jul 22, 2017 at 4:37 PM, K K Subbu <kksubbu...@gmail.com> wrote:
On Saturday 22 July 2017 06:51 PM, Tim Mackinnon wrote:
The one that stuck out for me (and is actually mentioned in another
thread this week) was the class/instance method difference. They
conceptually understood the difference coming from other languages
but our UI is tricky to understand with the Class button toggle we
have, and if you get methods on the wrong side, like with a test,
it's quite confusing.
It is an easy mistake to make and I have often seen this confusion in
beginners. With the attention on the methods panel and text input, it is
easy to overlook the class toggle button :-(.
An easy fix is to switch background color to differentiate between class and
instance methods in both code and input panels. A better way would be to use
tabs (like in Inspector).
BTW, I use the metaphor of toys (objects), moulds (classes) and mould
factory (metaclass). A mould is an object from the perspective of the mould
maker. Therefore operations on classes are 'methods' from the maker's
perspective (note the recursion!).
Anyway - this got me thinking - why do we bother having a toggle in
our UI for this these days? Of course we know there is a class and a
metaclass but given that we have icons for methods now (and also have
a Protocol pane ) why don't we just show all the methods we have in
one list and let you filter them or even see them all? It seems much
easier and way more efficient to rapidly code this way.
This perspective comes from the traditional way - code and compile. In
Pharo, we code one method at a time and sources are held in an external file
and a pointer stored in each method, so displaying all methods in one panel
would result in multiple file reads.
The only question then would be how to create methods of the right
type - whether to have a button to create the right template (and put
the browser code pane in the right context) or whether to indicate
it by convention of the method name when creating it like + new:
aSize etc. (Or even: class new: aSize etc).
The more I think about it, the more it seems like something we should
consider trying both for making ourselves more efficient (I'll bet
everyone has written a method on the wrong side by mistake) and also
helping newcomers.
Such mistakes are part of the learning curve and decrease with time.
Regards .. Subbu
