Smalltalk › Pharo › Pharo Smalltalk Users

Message naming

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

bahman

Message naming

Let's say I have a method with signature in a language like Java as below:
gregorianDayToJulianDay(year, month, day)

What could be a proper naming for this method in Smalltalk? I'm a bit
confused as I'm so used to the concept of methods being "verbs" which
accept some arguments.

I'd appreciate any help/idea.

--
Bahman Movaqar (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

signature.asc (565 bytes) Download Attachment

jtuchel

Re: Message naming

Bahman,

Am 13.11.13 08:43, schrieb Bahman Movaqar:
> Let's say I have a method with signature in a language like Java as below:
> gregorianDayToJulianDay(year, month, day)
>
> What could be a proper naming for this method in Smalltalk? I'm a bit
> confused as I'm so used to the concept of methods being "verbs" which
> accept some arguments.
>
> I'd appreciate any help/idea.
>
Thats always hard ;-)

I suggest a method name starting with 'convert' or 'as'. If you
implement the method on a specialized GregorianDate class, you can sure
omit the part for what you convert from, in a helper class you need to
keep it.

So let's assume you implement the method on a helper class. Then I'd suggest

#convertGregorianToJulianYear:month:day:

If you can change the order of parameters, it is even better (IMO) to
make the thing more like Date's newDay:month:year: (or
newDay:monthIndex:year). So we end up with:
#convertGregorainToJulianDay:month:year:

In case you have a specialized GregorianDate class:
GregorianDate>>#asJulianDay:month:year:

This is of course from a smalltalk perspective. If your goal is to keep
it recognizable for Java developers, keep the year:month:date ordering
and implement additional methods for the Smalltalk-minded that delegate
to the "originals" (or the other way round, that doesn't really matter).

So this is my train of thoughts about finding a good method name. Others
may think completely different.

HTH

Joachim

--
--  -----------------------------------------------------------------------  Objektfabrik Joachim Tuchel mailto:[hidden email]  Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

bahman

Re: Message naming

In reply to this post by bahman

On 11/13/2013 11:13, Bahman Movaqar wrote:
> Let's say I have a method with signature in a language like Java as below:
> gregorianDayToJulianDay(year, month, day)
>
> What could be a proper naming for this method in Smalltalk? I'm a bit
> confused as I'm so used to the concept of methods being "verbs" which
> accept some arguments.
>
> I'd appreciate any help/idea.

After reading Joachim's reply, I guess I have to explain a bit more:

I'm writing class that converts dates between Gregorian and Iranian
(a.k.a. Jalali) calendars. So the design I have (coming from a
verb-based perspective) is as follows:

<pseudo-design>
class: IranianCalendarConverter
"The only methods users should ever need to use"
class-side: GregorianToIranian(year, month, day) -> returns an
integer array (y, m, d)
class-side: IranianToGregorian(year, month, day) -> returns an
integer array (y, m, d)

"Internal methods used for calculation"
class-side: IranianDateToJulianDay(year, month, day) -> returns an
integer --Julian day
class-side: JulidanDayToGregorianDate(day) -> returns an integer
array (y, m, d)
class-side: GregorianDateToJulianDay(year, month, day) -> returns an
integer --Julian day
class-side: JulidanDayToIranianDate(day) -> returns an integer array
(y, m, d)
</pseudo-design>

Each of these methods contain about 10-30 lines of code.

--
Bahman Movaqar (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

signature.asc (565 bytes) Download Attachment

bahman

Re: Message naming

In reply to this post by jtuchel

On 11/13/2013 11:22, [hidden email] wrote:

> Bahman,
>
> Am 13.11.13 08:43, schrieb Bahman Movaqar:
>> Let's say I have a method with signature in a language like Java as
>> below:
>> gregorianDayToJulianDay(year, month, day)
>>
>> What could be a proper naming for this method in Smalltalk? I'm a bit
>> confused as I'm so used to the concept of methods being "verbs" which
>> accept some arguments.
>>
>> I'd appreciate any help/idea.
>>
> Thats always hard ;-)
>
> I suggest a method name starting with 'convert' or 'as'. If you
> implement the method on a specialized GregorianDate class, you can
> sure omit the part for what you convert from, in a helper class you
> need to keep it.
>
> So let's assume you implement the method on a helper class. Then I'd
> suggest
>
> #convertGregorianToJulianYear:month:day:

Thank you for your suggestions. They look fine but in all of them,
somehow, the word "Year" or "Day" becomes part of the message name,
which is somehow confusing, isn't it? Or maybe I'm not used to this
concept yet.

--
Bahman Movaqar (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

signature.asc (565 bytes) Download Attachment

Sven Van Caekenberghe-2

Re: Message naming

In reply to this post by jtuchel

On 13 Nov 2013, at 08:52, [hidden email] wrote:

> Bahman,
>
> Am 13.11.13 08:43, schrieb Bahman Movaqar:
>> Let's say I have a method with signature in a language like Java as below:
>> gregorianDayToJulianDay(year, month, day)
>>
>> What could be a proper naming for this method in Smalltalk? I'm a bit
>> confused as I'm so used to the concept of methods being "verbs" which
>> accept some arguments.
>>
>> I'd appreciate any help/idea.
>>
> Thats always hard ;-)
>
> I suggest a method name starting with 'convert' or 'as'. If you implement the method on a specialized GregorianDate class, you can sure omit the part for what you convert from, in a helper class you need to keep it.
>
> So let's assume you implement the method on a helper class. Then I'd suggest
>
> #convertGregorianToJulianYear:month:day:
>
> If you can change the order of parameters, it is even better (IMO) to make the thing more like Date's newDay:month:year: (or newDay:monthIndex:year). So we end up with:
> #convertGregorainToJulianDay:month:year:
>
> In case you have a specialized GregorianDate class:
> GregorianDate>>#asJulianDay:month:year:
>
> This is of course from a smalltalk perspective. If your goal is to keep it recognizable for Java developers, keep the year:month:date ordering and implement additional methods for the Smalltalk-minded that delegate to the "originals" (or the other way round, that doesn't really matter).
>
> So this is my train of thoughts about finding a good method name. Others may think completely different.

Your comments are valid in the context of a class method, but that is very close to a static global function, which is not very object oriented.

It of course depends on the class hierarchy (does it really make sense to both GregorianDate and JulianDate, time and data calculations can be very difficult).

So either

(GregorianDate newDay: 1 month: 1 year: 2010) asJulianDate

or even

(Date newDay: 1 month: 1 year: 2010) asJulianDate

where I assume the Julian calendar is the default.

Sven

PS: there is the Chronos library (http://www.squeaksource.com/Chronos/)

> HTH
>
> Joachim
>
> --
> --
> ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:[hidden email] Fliederweg 1 http://www.objektfabrik.de
> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com
> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
>
>

bahman

Re: Message naming

In reply to this post by bahman

On 11/13/2013 11:39, Bahman Movaqar wrote:
> On 11/13/2013 11:13, Bahman Movaqar wrote:
>> Let's say I have a method with signature in a language like Java as below:
>> gregorianDayToJulianDay(year, month, day)
>>
>> What could be a proper naming for this method in Smalltalk? I'm a bit
>> confused as I'm so used to the concept of methods being "verbs" which
>> accept some arguments.
>>
>> I'd appreciate any help/idea.

After reading Sven's reply, I came up with this design. Is it the
idiomatic way to handle this problem in Smalltalk:

<pseudo-design>
class JulianConverter:
instance variable: 'day'

#toGregorian
#toIranian

class GregorianConverter:
instance variable: 'year month day'

#toJulian

class IranianConverter:
instance variable: 'year month day'

#toJulian

</pseudo-design>

--
Bahman Movaqar (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

signature.asc (565 bytes) Download Attachment

Stéphane Ducasse

Re: Message naming

did you check

acancagua (unit and time)
or chronos (more complete calendar)
package

Stef

On Nov 13, 2013, at 9:19 AM, Bahman Movaqar <[hidden email]> wrote:

> On 11/13/2013 11:39, Bahman Movaqar wrote:
>> On 11/13/2013 11:13, Bahman Movaqar wrote:
>>> Let's say I have a method with signature in a language like Java as below:
>>> gregorianDayToJulianDay(year, month, day)
>>>
>>> What could be a proper naming for this method in Smalltalk? I'm a bit
>>> confused as I'm so used to the concept of methods being "verbs" which
>>> accept some arguments.
>>>
>>> I'd appreciate any help/idea.
>
> After reading Sven's reply, I came up with this design. Is it the
> idiomatic way to handle this problem in Smalltalk:
>
> <pseudo-design>
> class JulianConverter:
> instance variable: 'day'
>
> #toGregorian
> #toIranian
>
> class GregorianConverter:
> instance variable: 'year month day'
>
> #toJulian
>
> class IranianConverter:
> instance variable: 'year month day'
>
> #toJulian
>
> </pseudo-design>
>
> --
> Bahman Movaqar (http://BahmanM.com)
>
> ERP Evaluation, Implementation & Deployment Consultant
> PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
>
>

kilon.alios

Re: Message naming

In reply to this post by bahman

Thats not only the Pharo, the Squeak, way, the Python way, the Ruby way ..... its the logical way

GregorianDate >> toJulian

You have a class then you have a method . You want to extend your method ? why increase the size of method ? You just create a new class for it.

I have 3 rules when I code

1) Keep it small

2) Keep it simple

3) Keep it obvious

Also I cant recommend this book highly enough, its not only the best book I have read, its a goldmine of concentrated wisdom. No vague theories, no assumptions, just a bombarbment of practical examples -> http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X

it wont show you just proper naming it will show you everything. Its the kind of book that you will keep coming back to. This something that every coder should have.

and yes Java is doing it wrong, its doing it very wrong.

On Wed, Nov 13, 2013 at 10:19 AM, Bahman Movaqar <[hidden email]> wrote:

On 11/13/2013 11:39, Bahman Movaqar wrote:
> On 11/13/2013 11:13, Bahman Movaqar wrote:
>> Let's say I have a method with signature in a language like Java as below:
>> gregorianDayToJulianDay(year, month, day)
>>
>> What could be a proper naming for this method in Smalltalk? I'm a bit
>> confused as I'm so used to the concept of methods being "verbs" which
>> accept some arguments.
>>
>> I'd appreciate any help/idea.

After reading Sven's reply, I came up with this design. Is it the
idiomatic way to handle this problem in Smalltalk:

<pseudo-design>
class JulianConverter:
instance variable: 'day'

#toGregorian
#toIranian

class GregorianConverter:
instance variable: 'year month day'

#toJulian

class IranianConverter:
instance variable: 'year month day'

#toJulian

</pseudo-design>

--
Bahman Movaqar (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Sven Van Caekenberghe-2

Re: Message naming

In reply to this post by bahman

Hi Bahman,

On 13 Nov 2013, at 09:19, Bahman Movaqar <[hidden email]> wrote:

There is not necessarily a right and a wrong way. Design is hard to explain, I am not going to try. Sorry ;-)

But please do have a look at the Chronos library, it even has a PersianCalender, among many others. This is the class comment:

[Chronos] All code (classes and methods, and all associated documentation,) distributed as part of the Chronos Date/Time library are ¬© Copyright 2005-2006 by Alan L. Lovejoy. All Rights Reserved. Usage is controlled by the Chronos License (which is included in the distribution as the contents of the file {chronos-license.txt}, and is also available from the Chronos web site {http://www.chronos-st.org/License.html})

PersianCalendar

Concept:

PersianCalendar implements the arithmetical version of the Persian Calendar. There is also an astronomical version of the Persian Calendar, which some authorities claim is the one actually used in Iran, although other authorities claim otherwise. Chronos does not currently provide implementations of any astronomical calendars. The astronomical version of the Persian Calendar will (eventually) be implemented by class named AstronomicalPersianCalendar, whose registration key will be #'Persian-Astronomical'.

For any and all discussion of what a 'Calendar' is conceptually, how an instance of a Calendar can and/or should be used, the general implementation requirements for subclasses of Calendar, or the architectural requirements and responsibilities of Calendar instances with respect to the rest of the Chronos Date/Time Library, please refer to the documentation of class Calendar. The remainder of this text discusses the specific nature of the Persian Calendar itself (and its implementation by this class,) and assumes that the reader has already become familiar with all the concepts and terminology documented in class Calendar.

The Persian Calendar (as implemented here) is an arithmetical, solar calendar. A solar calendar is one that attempts to match the (average) length of its years to that of mean solar years.

Epoch Date

The epoch date of the Persian Calendar, 0001-01-01 [Persian], corresponds to 0622-03-22 [Gregorian] and to 0622-03-19 [Julian]. The Julian Date of the epoch of the Persian Calendar is 1,948,320.50 (midnight.)

The epoch date of the Persian Calendar is the vernal equinox of the year in which the "hijra" of Mohammed to Medina occurred ("hijra" means "flight from danger.")

The era of the Persian Calendar is called "Anno Persico" or "Anno Persarum" (AP)--which is Latin for "In the Year of Persia/the Persians."

Time-of-Day Clock

Modernly, midnight is both the zero-point of the time-of-day clock and also the initial moment of the day. However, such has not always been the case for all users of the Persian Calendar.

{PersianCalendar clock today}
{PersianCalendar clock now}

Year Numbering Policy

The Persian Calendar uses "zeroless ordinal" year numbering. This means that the epoch year is an ordinal number whose value is 1, and the year that immediately precedes the year 1 is the year -1.

Leap Year Rule

According to Birashk [A. Birashk, "A Comparative Calendar of the Iranian, Muslim Lunar, and Christian Eras for Three Thousand Years," Mazda Publishers (in association with Bibliotheca Persica,) Costa Mesa, CA, 1993], the arithmetical form of the Persian Calendar uses the following rather complicated leap year rules:

There is a master cycle of 2820 years, during which 683 years are leap years. Each standard year contains 365 days, and each leap year contains 366 days, so the master 2820-year cycle contains 1,029,983 days [(2820 * 365) + 683 = 1,029,983]. Based on the current mean length of the tropical year and solar day, there are 1,029,983.00118 days in 2820 tropical years. So, were it not for the fact that a) the length of the tropical year and the length of a mean solar day is slowly changing, and b) the length of the tropical year (which is defined by the duration between winter solstices) is not the same as the length of the spring equinoctial year (which is defined by the duration between vernal equinoxes,) it would be fair to say that the Persian arithmetical calendar deviates from the length of a year by only 101.952 minutes in 2820 years. But for those (and other) caveats, the Persian arithmetical calendar would slip from perfect alignment with the tropical year by only one day every 39,829.68 years--which is astounding accuracy, in spite of the caveats.

Within each 2820-year cycle, there are 22 subcycles--the first 21 each contain 128 years, and the 22nd (final) subcycle contains 132 years [2820 = 21 * 128 + 132].

Each 128-year subcycle contains one 29-year sub-subcycle (the first,) followed by three 33-year sub-subcycles [128 = 29 + (3 * 33)].

Each 132-year subcycle contains one 29-year sub-subcycle (the first,) followed by two 33-year sub-subcycles, followed by one 37-year sub-subcycle [132 = 29 + (2 * 33) + 37].

A year in a sub-subcycle (whether it contains 29, 33 or 37 years) is a leap year if the ordinal index of the year within the cycle satisfies the following two predicate tests: 1) it's greater than 1, and 2) the remainder after dividing it by 4 is 1 (so the first year in sub-subcyle is never a leap year; the first leap year is the fifth year in the sub-subcycle.) Thus, a 29-year sub-subcycle has 7 leap years, a 33-year sub-subcycle has 8 leap years, and a 37-year sub-subcycle has 9 leap years (Note: the last year of a sub-subcycle is always a leap year, since 29, 33 and 37 all result in a remainder of 1 when divided by 4) [21 * (7 + (3 * 8)) + (7 + (2 * 8) + 9) = 683].

The base year of the 2820 cycle of years is NOT the Persian year zero or 1, however. The base year of the 2820-year cycle of years is the Persian year 475 (which starts on 21 March 1096 [Gregorian] or 15 March 1096 [Julian].) However, to facilitate the use of modular arithmetic, the Chronos implementation uses Persian year 474 as the zeroeth year of the 2820-year cycle.

Algorithm of Predicate Function that answers true if a <persianYear> is a leap year (input arg=<persianYear>):

1. If <persianYear> >= 1 then
set <cardinalYear> to <persianYear> - 1;
else
set <cardinalYear> to <persianYear>;
end
2. Set <dividend> to <cardinalYear> - 473.
3. Set <year> to (dividend mod 2820) + 474.
4. Return (((<year> + 38) * 682) mod 2816) < 682

Month Structure

Month Days In Month
Standard Year/Leap Year
1: Farvardin 31/31
2: Ordibehesht 31/31
3: Xordad 31/31
4: Tir 31/31
5: Mordad 31/31
6: Shahrivar 31/31
7: Mehr 30/30
8: Aban 30/30
9: Azar 30/30
10: Dey 30/30
11: Bahman 30/30
12: Esfand 29/30

Days In Year 365/366

The semantic month-key of a month is the same as the month's (English) name (as given here.)

Pretty deep, right ?

HTH,

Sven

Yes, the main website is down, but you should be able to load the code in Pharo 2.0 using the configuration.

> --
> Bahman Movaqar (http://BahmanM.com)
>
> ERP Evaluation, Implementation & Deployment Consultant
> PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
>
>

bahman

Re: Message naming

@Sven
> There is not necessarily a right and a wrong way. Design is hard to
> explain, I am not going to try. Sorry ;-)

Of course! I was just trying to find out the design *norm* for a small
problem; to become familiar with the popular way of thought among
Smalltalk'ers.

@kilon
Thanks. I think that may be what I need: real world examples.

As I have already admitted, I am not used to Smalltalk way of thinking.
This is the first language I know, that enforces OOP by design, none of
Java, Python, C++ or Scala does. It's ironic; OOP concepts and
techniques were among the first things I was taught back in University
but now the more I think about Smalltalk's syntax and design, the more I
get closer to the conclusion that I didn't use pure OOP many times
during my career. And, I believe, it was simply because the development
platforms never enforced it the way Smalltalk does: in a clever and
camouflaged way.

> But please do have a look at the Chronos library, it even has a
PersianCalender, among many others.

I knew about Chronos. Someone here, kindly suggested it about 6 months
ago when I asked about such a thing. I'm not trying to re-write
something like Chronos rather I'm trying to get my hands dirty with
Pharo and also re-visit my OOP skills. Thanks.

--
Bahman Movaqar (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

signature.asc (565 bytes) Download Attachment

kilon.alios

Re: Message naming

I dont know exactly what you mean by eforced OOP by design. Pharo design principles are not written in stone, just good habits people picked along the way and they are to be found in python as well. Python actually takes OO very deply , sure if , else, while are language constructs but rest assured that everything else is an object. For example unlike Pharo , python allows to do procedural programming , but python functions are objects in disguise . You could say that python functions work similarly (but not the same , since closures are not supported in python) to Pharo blocks.

Ruby is even closer to Pharo, supporting blocks, message passing etc. Also those kind of languages take clean design in code, very seriously. Just go to python interpreter console and do "import this" and you will see the zen of python unfold before your eyes emphasizing the good design principles you will find many smalltalkers talking about. Another language taking these principles very seriously is Lisp, actually Smalltalk took a lot from lisp in terms of overall design and direction.

Of course clean code in the end is a choice , there is no enforcement, you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There is no capital punishment for coders that don't follow these principles. Many coders care only for getting the job done and feel like they dont have time to worry about how clean their code is. Its a free world, or so we hope.

On the other hand everything should be put into context and never taken as the Holy Bible or Holy Grail.

On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <[hidden email]> wrote:

@Sven

> There is not necessarily a right and a wrong way. Design is hard to
> explain, I am not going to try. Sorry ;-)

Of course! I was just trying to find out the design *norm* for a small
problem; to become familiar with the popular way of thought among
Smalltalk'ers.

@kilon
Thanks. I think that may be what I need: real world examples.

As I have already admitted, I am not used to Smalltalk way of thinking.
This is the first language I know, that enforces OOP by design, none of
Java, Python, C++ or Scala does. It's ironic; OOP concepts and
techniques were among the first things I was taught back in University
but now the more I think about Smalltalk's syntax and design, the more I
get closer to the conclusion that I didn't use pure OOP many times
during my career. And, I believe, it was simply because the development
platforms never enforced it the way Smalltalk does: in a clever and
camouflaged way.

> But please do have a look at the Chronos library, it even has a
PersianCalender, among many others.

I knew about Chronos. Someone here, kindly suggested it about 6 months
ago when I asked about such a thing. I'm not trying to re-write
something like Chronos rather I'm trying to get my hands dirty with
Pharo and also re-visit my OOP skills. Thanks.

--
Bahman Movaqar (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

bahman

Re: Message naming

Kilon, I believe there's a subtle difference between Python, Java, Ruby and Scala on one side and Smalltalk on the other:
All those 4 languages are more or less implemented as OO languages with the famous statement "everything is an object". However they are syntactically and semantically designed in a way that they allow a not OO design to be coded. Just imagine the small problem I shared in this thread; in any of those languages I can do it with one class and a couple of static methods and the code will definitely *read and work naturally correct*.

On the other hand, consider Smalltalk: "everything is an object", but the syntax and semantics of the language is different. Yes, it allows a not OO design to be coded but there's a difference: think about my small problem again. The moment I thought about coding it the old style (single class with static methods) something started to smell. It smelled so bad that I had to consult you folks.

That's what I'm talking about: a tiny but subtle and well thought out difference in the syntax and semantics and it makes a huge difference.

Another example:
I -like all of you- had studied, heard, read and practiced bottom-to-top design and I thought I knew what it meant. However, the moment I started coding in Lisp I found out I knew little about that paradigm. The natural subtle semantic design of Lisp made it a natural bottom-to-top platform nothing like any other platform I had seen until then.

On 11/13/2013 18:27, kilon alios wrote:

I dont know exactly what you mean by eforced OOP by design. Pharo design principles are not written in stone, just good habits people picked along the way and they are to be found in python as well. Python actually takes OO very deply , sure if , else, while are language constructs but rest assured that everything else is an object. For example unlike Pharo , python allows to do procedural programming , but python functions are objects in disguise . You could say that python functions work similarly (but not the same , since closures are not supported in python) to Pharo blocks.

Ruby is even closer to Pharo, supporting blocks, message passing etc. Also those kind of languages take clean design in code, very seriously. Just go to python interpreter console and do "import this" and you will see the zen of python unfold before your eyes emphasizing the good design principles you will find many smalltalkers talking about. Another language taking these principles very seriously is Lisp, actually Smalltalk took a lot from lisp in terms of overall design and direction.

Of course clean code in the end is a choice , there is no enforcement, you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There is no capital punishment for coders that don't follow these principles. Many coders care only for getting the job done and feel like they dont have time to worry about how clean their code is. Its a free world, or so we hope.

On the other hand everything should be put into context and never taken as the Holy Bible or Holy Grail.

On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <[hidden email]> wrote:

@Sven

> There is not necessarily a right and a wrong way. Design is hard to
> explain, I am not going to try. Sorry ;-)

Of course! I was just trying to find out the design *norm* for a small
problem; to become familiar with the popular way of thought among
Smalltalk'ers.

@kilon
Thanks. I think that may be what I need: real world examples.

As I have already admitted, I am not used to Smalltalk way of thinking.
This is the first language I know, that enforces OOP by design, none of
Java, Python, C++ or Scala does. It's ironic; OOP concepts and
techniques were among the first things I was taught back in University
but now the more I think about Smalltalk's syntax and design, the more I
get closer to the conclusion that I didn't use pure OOP many times
during my career. And, I believe, it was simply because the development
platforms never enforced it the way Smalltalk does: in a clever and
camouflaged way.

> But please do have a look at the Chronos library, it even has a
PersianCalender, among many others.

I knew about Chronos. Someone here, kindly suggested it about 6 months
ago when I asked about such a thing. I'm not trying to re-write
something like Chronos rather I'm trying to get my hands dirty with
Pharo and also re-visit my OOP skills. Thanks.

-- 
Bahman Movaqar  (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

signature.asc (565 bytes) Download Attachment

nacho

Re: Message naming

In reply to this post by kilon.alios

Kilon, great reflection.

We should have Pharo display Pharo Zen as exposed in Pharo Vision:

Pharo Zen

Our values and convictions are condensed in this simple list.

Easy to understand, easy to learn from, easy to change. Objects all the way down.
Examples to learn from.
Fully dynamic and malleable.

Beauty in the code, beauty in the comments.
Simplicity is the ultimate elegance.
Better a set of small polymorphic classes than a large ugly one. Classes structure our vocabulary.
Messages are our vocabulary.
Polymorphism is our esperanto.
Abstraction and composition are our friends.
Tests are important but can be changed.
Explicit is better than implicit.
Magic only at the right place.
One step at a time.
There is no unimportant fix.
Learning from mistakes.
Perfection can kill movement.
Quality is a emerging property.
Simple processes to support progress.
Communication is key.
A system with robust abstractions that a single person can understand.

best

nacho

Lic. Ignacio Sniechowski, MBA

On Wed, Nov 13, 2013 at 11:57 AM, kilon alios <[hidden email]> wrote:

I dont know exactly what you mean by eforced OOP by design. Pharo design principles are not written in stone, just good habits people picked along the way and they are to be found in python as well. Python actually takes OO very deply , sure if , else, while are language constructs but rest assured that everything else is an object. For example unlike Pharo , python allows to do procedural programming , but python functions are objects in disguise . You could say that python functions work similarly (but not the same , since closures are not supported in python) to Pharo blocks.

Ruby is even closer to Pharo, supporting blocks, message passing etc. Also those kind of languages take clean design in code, very seriously. Just go to python interpreter console and do "import this" and you will see the zen of python unfold before your eyes emphasizing the good design principles you will find many smalltalkers talking about. Another language taking these principles very seriously is Lisp, actually Smalltalk took a lot from lisp in terms of overall design and direction.

Of course clean code in the end is a choice , there is no enforcement, you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There is no capital punishment for coders that don't follow these principles. Many coders care only for getting the job done and feel like they dont have time to worry about how clean their code is. Its a free world, or so we hope.

On the other hand everything should be put into context and never taken as the Holy Bible or Holy Grail.

On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <[hidden email]> wrote:

@Sven

> There is not necessarily a right and a wrong way. Design is hard to
> explain, I am not going to try. Sorry ;-)

Of course! I was just trying to find out the design *norm* for a small
problem; to become familiar with the popular way of thought among
Smalltalk'ers.

@kilon
Thanks. I think that may be what I need: real world examples.

As I have already admitted, I am not used to Smalltalk way of thinking.
This is the first language I know, that enforces OOP by design, none of
Java, Python, C++ or Scala does. It's ironic; OOP concepts and
techniques were among the first things I was taught back in University
but now the more I think about Smalltalk's syntax and design, the more I
get closer to the conclusion that I didn't use pure OOP many times
during my career. And, I believe, it was simply because the development
platforms never enforced it the way Smalltalk does: in a clever and
camouflaged way.

> But please do have a look at the Chronos library, it even has a
PersianCalender, among many others.

I knew about Chronos. Someone here, kindly suggested it about 6 months
ago when I asked about such a thing. I'm not trying to re-write
something like Chronos rather I'm trying to get my hands dirty with
Pharo and also re-visit my OOP skills. Thanks.

--
Bahman Movaqar (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nacho Smalltalker apprentice. Buenos Aires, Argentina.

kilon.alios

Re: Message naming

In reply to this post by bahman

What I tried to say here was that it was a mistake to blame the language itself for code design. Sure a language may have some ugly sides to it, it may even make it not so easy to create clean code but in the end of the day clean and readable code is up to the coder at least 90% .

I would not say that there are subtle differences between Python and Java , Ruby and Scala just by themselves. The differences are quite big actually. My point was that good design is something that many if not most languages promote. Why ? Because nobody likes ugly code. Actually most java developers hate long names for methods, there is even a quora question on the subject that many Java coders express their frustration on the subject.

For example your naming issues is pretty much the foundation of design of Python's Standard Library , one of the most respected included libraries in the programming world.

This is the zen of python :

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

As you can see obviously from this Zen , long names and monolithic approaches are out of the door.

So if you think that python would motivate you to use long names for methods , then you are easily mistaken and you better ask some python coders what they think a "pythonic" code really looks like. You will be suprized how much common ground you will find with Pharo people. I am willing to bet Ruby folks will be even more inclined to follow smalltalk values since their language was largely based on smalltalk.

Ignacio, I think its a great idea to have a Zen as a community. In the python world its started as a joke, then it was viewed as a serious joke, currently is viewed as something so serious, that if a library does not follow it its regarded as "unpythonic" and believe me no python coder wants his code to be called unpythonic. So even though the zen is not very specific I think it clearly shows the direction of what python community considers as good code.

Should Pharo have something similar ? its certainly should have. I think its important to have values, to aspire to create better designed code, to not repeat the mistakes of the past or mistakes of others, to pass knowledge and experience around.

The trend for modern coding is to move closer to this area, smaller libraries are in favor instead of large libs, documentation plays a much more important role, OO mixed with other paradigms like functional programming etc gives even more freedom of choice, the rule of least surprise is followed more and more.  Where some see smalltalk as a dead or niche language, I see it being used everywhere and by everyone to lesser or bigger degree. This is is our future.

On Wed, Nov 13, 2013 at 5:29 PM, Bahman Movaqar <[hidden email]> wrote:

Kilon, I believe there's a subtle difference between Python, Java, Ruby and Scala on one side and Smalltalk on the other:
All those 4 languages are more or less implemented as OO languages with the famous statement "everything is an object". However they are syntactically and semantically designed in a way that they allow a not OO design to be coded. Just imagine the small problem I shared in this thread; in any of those languages I can do it with one class and a couple of static methods and the code will definitely *read and work naturally correct*.

On the other hand, consider Smalltalk: "everything is an object", but the syntax and semantics of the language is different. Yes, it allows a not OO design to be coded but there's a difference: think about my small problem again. The moment I thought about coding it the old style (single class with static methods) something started to smell. It smelled so bad that I had to consult you folks.

That's what I'm talking about: a tiny but subtle and well thought out difference in the syntax and semantics and it makes a huge difference.

Another example:
I -like all of you- had studied, heard, read and practiced bottom-to-top design and I thought I knew what it meant. However, the moment I started coding in Lisp I found out I knew little about that paradigm. The natural subtle semantic design of Lisp made it a natural bottom-to-top platform nothing like any other platform I had seen until then.

On 11/13/2013 18:27, kilon alios wrote:
I dont know exactly what you mean by eforced OOP by design. Pharo design principles are not written in stone, just good habits people picked along the way and they are to be found in python as well. Python actually takes OO very deply , sure if , else, while are language constructs but rest assured that everything else is an object. For example unlike Pharo , python allows to do procedural programming , but python functions are objects in disguise . You could say that python functions work similarly (but not the same , since closures are not supported in python) to Pharo blocks.

Ruby is even closer to Pharo, supporting blocks, message passing etc. Also those kind of languages take clean design in code, very seriously. Just go to python interpreter console and do "import this" and you will see the zen of python unfold before your eyes emphasizing the good design principles you will find many smalltalkers talking about. Another language taking these principles very seriously is Lisp, actually Smalltalk took a lot from lisp in terms of overall design and direction.

Of course clean code in the end is a choice , there is no enforcement, you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There is no capital punishment for coders that don't follow these principles. Many coders care only for getting the job done and feel like they dont have time to worry about how clean their code is. Its a free world, or so we hope.

On the other hand everything should be put into context and never taken as the Holy Bible or Holy Grail.

On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <[hidden email]> wrote:

@Sven

> There is not necessarily a right and a wrong way. Design is hard to
> explain, I am not going to try. Sorry ;-)

Of course! I was just trying to find out the design *norm* for a small
problem; to become familiar with the popular way of thought among
Smalltalk'ers.

@kilon
Thanks. I think that may be what I need: real world examples.

As I have already admitted, I am not used to Smalltalk way of thinking.
This is the first language I know, that enforces OOP by design, none of
Java, Python, C++ or Scala does. It's ironic; OOP concepts and
techniques were among the first things I was taught back in University
but now the more I think about Smalltalk's syntax and design, the more I
get closer to the conclusion that I didn't use pure OOP many times
during my career. And, I believe, it was simply because the development
platforms never enforced it the way Smalltalk does: in a clever and
camouflaged way.

> But please do have a look at the Chronos library, it even has a
PersianCalender, among many others.

I knew about Chronos. Someone here, kindly suggested it about 6 months
ago when I asked about such a thing. I'm not trying to re-write
something like Chronos rather I'm trying to get my hands dirty with
Pharo and also re-visit my OOP skills. Thanks.
-- 
Bahman Movaqar  (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Stéphane Ducasse

Re: Message naming

In reply to this post by nacho

Kilon, great reflection.
We should have Pharo display Pharo Zen as exposed in Pharo Vision:

Pharo Zen
Our values and convictions are condensed in this simple list.
Easy to understand, easy to learn from, easy to change. Objects all the way down.
Examples to learn from.
Fully dynamic and malleable.
Beauty in the code, beauty in the comments.
Simplicity is the ultimate elegance.
Better a set of small polymorphic classes than a large ugly one. Classes structure our vocabulary.
Messages are our vocabulary.
Polymorphism is our esperanto.
Abstraction and composition are our friends.
Tests are important but can be changed.
Explicit is better than implicit.
Magic only at the right place.
One step at a time.
There is no unimportant fix.
Learning from mistakes.
Perfection can kill movement.
Quality is a emerging property.
Simple processes to support progress.
Communication is key.
A system with robust abstractions that a single person can understand.

:D
best
nacho

Lic. Ignacio Sniechowski, MBA

On Wed, Nov 13, 2013 at 11:57 AM, kilon alios <[hidden email]> wrote:

I dont know exactly what you mean by eforced OOP by design. Pharo design principles are not written in stone, just good habits people picked along the way and they are to be found in python as well. Python actually takes OO very deply , sure if , else, while are language constructs but rest assured that everything else is an object. For example unlike Pharo , python allows to do procedural programming , but python functions are objects in disguise . You could say that python functions work similarly (but not the same , since closures are not supported in python) to Pharo blocks.

Ruby is even closer to Pharo, supporting blocks, message passing etc. Also those kind of languages take clean design in code, very seriously. Just go to python interpreter console and do "import this" and you will see the zen of python unfold before your eyes emphasizing the good design principles you will find many smalltalkers talking about. Another language taking these principles very seriously is Lisp, actually Smalltalk took a lot from lisp in terms of overall design and direction.

Of course clean code in the end is a choice , there is no enforcement, you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There is no capital punishment for coders that don't follow these principles. Many coders care only for getting the job done and feel like they dont have time to worry about how clean their code is. Its a free world, or so we hope.

On the other hand everything should be put into context and never taken as the Holy Bible or Holy Grail.

On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <[hidden email]> wrote:

@Sven

> There is not necessarily a right and a wrong way. Design is hard to
> explain, I am not going to try. Sorry ;-)

Of course! I was just trying to find out the design *norm* for a small
problem; to become familiar with the popular way of thought among
Smalltalk'ers.

@kilon
Thanks. I think that may be what I need: real world examples.

As I have already admitted, I am not used to Smalltalk way of thinking.
This is the first language I know, that enforces OOP by design, none of
Java, Python, C++ or Scala does. It's ironic; OOP concepts and
techniques were among the first things I was taught back in University
but now the more I think about Smalltalk's syntax and design, the more I
get closer to the conclusion that I didn't use pure OOP many times
during my career. And, I believe, it was simply because the development
platforms never enforced it the way Smalltalk does: in a clever and
camouflaged way.

> But please do have a look at the Chronos library, it even has a
PersianCalender, among many others.

I knew about Chronos. Someone here, kindly suggested it about 6 months
ago when I asked about such a thing. I'm not trying to re-write
something like Chronos rather I'm trying to get my hands dirty with
Pharo and also re-visit my OOP skills. Thanks.

--
Bahman Movaqar (http://BahmanM.com)

ERP Evaluation, Implementation & Deployment Consultant
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)