Author class

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Author class

Miguel Cobá
I'm fixing a bug in the world menu -> System -> Preferences -> "set
author initials".

Questions?

The package it is Morphic, the class is TheWorldMenu.

This package, in the last core image is modified but not commited so
when following the steps
from the HowToContribute wiki page, in the part of creating a mcz
package with the change the mcz
generate will include the other uncommited changes. Should I use a
changeset instead in order to not
commit changes that I don't want?

What is the goal with the Author class? I can see that the Utilities
methods that used to be use to set
author name and initials are being replaced with calls to Author.
Also, they are deprecated in Utilities.
Questions:

Author has name and initials, what will be the intended use of them?
By previous mails in the list I remember
that Pharo doesn't want to use initials (like mcm, lr, avi) but full
name as hinted by the message prompt in
the Author requestName. But then initials will have exactly the same
that name in the author class?

I can unify all the message sends to Author in the core image, also I
can unify the initials and name usage, but
I need to know the intended goal for this class.

What is the goal?

Cheers,
Miguel Cobá

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Alexandre Bergel
> This package, in the last core image is modified but not commited so
> when following the steps
> from the HowToContribute wiki page, in the part of creating a mcz
> package with the change the mcz
> generate will include the other uncommited changes. Should I use a
> changeset instead in order to not
> commit changes that I don't want?

First, you should update your image. It should be a core. Your change  
must be produced for Core.
Then, implement your fixe. If more than one package is touched, then  
produce a slice. You should save your fix in PharoInbox using  
Monticello.
Last step, make sure your fix load in a fresh and updated core image;  
add an issue in the google website; send an email to the mailing list.

> What is the goal with the Author class?

A reification of author. Authors should not be strings passed around.

> Author has name and initials, what will be the intended use of them?

It is true that we should not use initials anymore, but essentially  
for legacy purpose, we cannot remove them.
We could envision future version of the class Author that includes  
email, squeak source account, ...

> I can unify all the message sends to Author in the core image, also I
> can unify the initials and name usage, but
> I need to know the intended goal for this class.

The only use of Author is for managing the name/initial used in  
the .changes and monticello.

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Stéphane Ducasse
In reply to this post by Miguel Cobá
>
>
> What is the goal with the Author class? I can see that the Utilities
> methods that used to be use to set
> author name and initials are being replaced with calls to Author.
> Also, they are deprecated in Utilities.
> Questions:
>
> Author has name and initials, what will be the intended use of them?

We should not use initials.
We should not use Utilities in the future.

> By previous mails in the list I remember
> that Pharo doesn't want to use initials (like mcm, lr, avi) but full
> name as hinted by the message prompt in
> the Author requestName. But then initials will have exactly the same
> that name in the author class?

It should be cleaned but nobody took the time.

> I can unify all the message sends to Author in the core image, also I
> can unify the initials and name usage, but

It would be nice :)
The prompt should ask for firstname.lastname and not initials :)

> I need to know the intended goal for this class.
>
> What is the goal?

To represent metadata of the author.
Probably having initial and password for monticello/ squeaksource  
makes sense.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Miguel Cobá
In reply to this post by Alexandre Bergel
On Wed, Jul 22, 2009 at 2:25 PM, Alexandre Bergel<[hidden email]> wrote:

>> This package, in the last core image is modified but not commited so
>> when following the steps
>> from the HowToContribute wiki page, in the part of creating a mcz
>> package with the change the mcz
>> generate will include the other uncommited changes. Should I use a
>> changeset instead in order to not
>> commit changes that I don't want?
>
> First, you should update your image. It should be a core. Your change
> must be produced for Core.
> Then, implement your fixe. If more than one package is touched, then
> produce a slice. You should save your fix in PharoInbox using
> Monticello.
> Last step, make sure your fix load in a fresh and updated core image;
> add an issue in the google website; send an email to the mailing list.
>
Yes, I know, that is what I was doing.

My confusion was when opening the changes windows in the monticello
browser for the morphic package. I saw not just the change of my changeset,
but also the last changes to the package, that is because I thought that were
uncommited packages
Now I have checked the generated mcz following the process and indeed it only
contains my change. I will push it to PharoInbox.

>> What is the goal with the Author class?
>
> A reification of author. Authors should not be strings passed around.
>
>> Author has name and initials, what will be the intended use of them?
>
> It is true that we should not use initials anymore, but essentially
> for legacy purpose, we cannot remove them.
> We could envision future version of the class Author that includes
> email, squeak source account, ...

Yes but I mean, in a clean core image, on first method save it asks
for the initials,
this is stored on the initials inst var of the singleton Author.

But on the World Menu, the set author name, it stores (in a
firstname.lastname format) the
value entered in the name inst var

So, setting one, doesn't set the other.
Also, the messages are different for each one (rightly, because are
different things) but I
want to know what is the inteded behavior from now on to trying to do
the changes.

Is the user only asked for name (forcing a format like
firstname.lastname) and the initials
are calculated accordingly?

Are the initials doomed to disappear, and the only interface will be
the name (and possibly the
email and other fields mentioned) to identify a person? This means to
modify all the senders to
initial methods and point them to name methods. With the time, the
initials inst var will be droped
from the Author class.


Thanks for your answers,
Miguel Cobá

>
>> I can unify all the message sends to Author in the core image, also I
>> can unify the initials and name usage, but
>> I need to know the intended goal for this class.
>
> The only use of Author is for managing the name/initial used in
> the .changes and monticello.
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Stéphane Ducasse
>
> Yes but I mean, in a clean core image, on first method save it asks
> for the initials,
> this is stored on the initials inst var of the singleton Author.
>
> But on the World Menu, the set author name, it stores (in a
> firstname.lastname format) the
> value entered in the name inst var
>
> So, setting one, doesn't set the other.
> Also, the messages are different for each one (rightly, because are
> different things) but I
> want to know what is the inteded behavior from now on to trying to do
> the changes.

Yes this is the mess.
Can you propose a nice solution?

> Is the user only asked for name (forcing a format like
> firstname.lastname) and the initials
> are calculated accordingly?

would be good but some people on ss have funky initials because theirs  
were taken.
This is why initials does not scale.

> Are the initials doomed to disappear, and the only interface will be
> the name (and possibly the
> email and other fields mentioned) to identify a person? This means to
> modify all the senders to
> initial methods and point them to name methods. With the time, the
> initials inst var will be droped
> from the Author class.

I think so.



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Miguel Cobá
In reply to this post by Stéphane Ducasse
On Wed, Jul 22, 2009 at 2:53 PM, Stéphane
Ducasse<[hidden email]> wrote:

>>
>>
>> What is the goal with the Author class? I can see that the Utilities
>> methods that used to be use to set
>> author name and initials are being replaced with calls to Author.
>> Also, they are deprecated in Utilities.
>> Questions:
>>
>> Author has name and initials, what will be the intended use of them?
>
> We should not use initials.

This means that all the methods referencing initials should be
replaced with calls
to equivalent name methods?

> We should not use Utilities in the future.
>
>> By previous mails in the list I remember
>> that Pharo doesn't want to use initials (like mcm, lr, avi) but full
>> name as hinted by the message prompt in
>> the Author requestName. But then initials will have exactly the same
>> that name in the author class?
>
> It should be cleaned but nobody took the time.
>

I can do, but I need more directions

>> I can unify all the message sends to Author in the core image, also I
>> can unify the initials and name usage, but
>
> It would be nice :)
> The prompt should ask for firstname.lastname and not initials :)
>

So I can replace all the prompts to initials for name in the format you mention.

Will this format be the prefered/oficial one?
Will other formats be allowed? Maybe asking for firstname and then for
lastname and
then inside Author concatenating in a firstname.lastname.

What happens with someone with two firstnames and lastnames, like me:

Miguel Enrique Cobá Martínez

Firstname: Miguel Enrique
Lastname: Cobá Martínez

yes it is an bad example as I would write:

Firstname: Miguel
Lastname: Cobá

What about spaces?

>> I need to know the intended goal for this class.
>>
>> What is the goal?
>
> To represent metadata of the author.
> Probably having initial and password for monticello/ squeaksource
> makes sense.
>
>

What is the reason to store the password, to automate login to squeaksource, or
something like that?

Thanks,
Miguel Cobá
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Miguel Cobá
Also, check this bug in mantis

http://bugs.squeak.org/view.php?id=6993

It can be added to the author class also and unify them in a single place.


On Wed, Jul 22, 2009 at 4:35 PM, Miguel Cobá<[hidden email]> wrote:

> On Wed, Jul 22, 2009 at 2:53 PM, Stéphane
> Ducasse<[hidden email]> wrote:
>>>
>>>
>>> What is the goal with the Author class? I can see that the Utilities
>>> methods that used to be use to set
>>> author name and initials are being replaced with calls to Author.
>>> Also, they are deprecated in Utilities.
>>> Questions:
>>>
>>> Author has name and initials, what will be the intended use of them?
>>
>> We should not use initials.
>
> This means that all the methods referencing initials should be
> replaced with calls
> to equivalent name methods?
>
>> We should not use Utilities in the future.
>>
>>> By previous mails in the list I remember
>>> that Pharo doesn't want to use initials (like mcm, lr, avi) but full
>>> name as hinted by the message prompt in
>>> the Author requestName. But then initials will have exactly the same
>>> that name in the author class?
>>
>> It should be cleaned but nobody took the time.
>>
>
> I can do, but I need more directions
>
>>> I can unify all the message sends to Author in the core image, also I
>>> can unify the initials and name usage, but
>>
>> It would be nice :)
>> The prompt should ask for firstname.lastname and not initials :)
>>
>
> So I can replace all the prompts to initials for name in the format you mention.
>
> Will this format be the prefered/oficial one?
> Will other formats be allowed? Maybe asking for firstname and then for
> lastname and
> then inside Author concatenating in a firstname.lastname.
>
> What happens with someone with two firstnames and lastnames, like me:
>
> Miguel Enrique Cobá Martínez
>
> Firstname: Miguel Enrique
> Lastname: Cobá Martínez
>
> yes it is an bad example as I would write:
>
> Firstname: Miguel
> Lastname: Cobá
>
> What about spaces?
>
>>> I need to know the intended goal for this class.
>>>
>>> What is the goal?
>>
>> To represent metadata of the author.
>> Probably having initial and password for monticello/ squeaksource
>> makes sense.
>>
>>
>
> What is the reason to store the password, to automate login to squeaksource, or
> something like that?
>
> Thanks,
> Miguel Cobá
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Miguel Cobá
In reply to this post by Stéphane Ducasse
On Wed, Jul 22, 2009 at 4:32 PM, Stéphane
Ducasse<[hidden email]> wrote:

>>
>> Yes but I mean, in a clean core image, on first method save it asks
>> for the initials,
>> this is stored on the initials inst var of the singleton Author.
>>
>> But on the World Menu, the set author name, it stores (in a
>> firstname.lastname format) the
>> value entered in the name inst var
>>
>> So, setting one, doesn't set the other.
>> Also, the messages are different for each one (rightly, because are
>> different things) but I
>> want to know what is the inteded behavior from now on to trying to do
>> the changes.
>
> Yes this is the mess.
> Can you propose a nice solution?

Ok, this is the proposal.

The Author class will use only the name inst var and related methods.
The initials related are to be unused and later droped in a subsecuent release.

All the calls to initials methods will be replaced by names methods.

The format for the name will be free, and suggested by the prompt message to

firstname.lastname

but not enforced.

It will not allow spaces, just letters and periods in places of spaces e.g.

Miguel Cobá -> miguel.coba
John The Hacker -> john.the.hacker
Peter O'Toole -> peter.otoole or maybe peter.o.toole

This period in place of space can be discussed because monticello
replaces periods for "_".
Maybe 'firstname_lastname' should be suggested in the prompt.

Every package not in core that use the initial methods should be
allowed to use the deprecated
initials methods but strongly urged to change to the names methods.

At least in core, the initials should not be used anymore.

What do you think?

Miguel Cobá


>
>> Is the user only asked for name (forcing a format like
>> firstname.lastname) and the initials
>> are calculated accordingly?
>
> would be good but some people on ss have funky initials because theirs
> were taken.
> This is why initials does not scale.
>
>> Are the initials doomed to disappear, and the only interface will be
>> the name (and possibly the
>> email and other fields mentioned) to identify a person? This means to
>> modify all the senders to
>> initial methods and point them to name methods. With the time, the
>> initials inst var will be droped
>> from the Author class.
>
> I think so.
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Douglas Brebner
In reply to this post by Miguel Cobá
Miguel Cobá wrote:

> On Wed, Jul 22, 2009 at 2:53 PM, Stéphane
> Ducasse<[hidden email]> wrote:
>>> I can unify all the message sends to Author in the core image, also I
>>> can unify the initials and name usage, but
>>>      
>> It would be nice :)
>> The prompt should ask for firstname.lastname and not initials :)
>>
>>    
>
> So I can replace all the prompts to initials for name in the format you mention.
>
> Will this format be the prefered/oficial one?
> Will other formats be allowed? Maybe asking for firstname and then for
> lastname and
> then inside Author concatenating in a firstname.lastname.
>
> What happens with someone with two firstnames and lastnames, like me:
>
> Miguel Enrique Cobá Martínez
>
> Firstname: Miguel Enrique
> Lastname: Cobá Martínez
>
> yes it is an bad example as I would write:
>
> Firstname: Miguel
> Lastname: Cobá
>
> What about spaces?
>  

Spaces aren't avoidable since some names have them e.g. "von Braun".
Other things to consider are some cultures (like japanese) write names
lastname, firstname and others have non-letter chars in their names e.g.
irish names can have apostrophies like "O'Brien" and double barrelled
names can have dashes.

The best way to do it might be to just have a field for you to input
your name in your preferred form since proper international name
handling is complicated.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Miguel Cobá
On Wed, Jul 22, 2009 at 5:58 PM, Douglas
Brebner<[hidden email]> wrote:

> Miguel Cobá wrote:
>> On Wed, Jul 22, 2009 at 2:53 PM, Stéphane
>> Ducasse<[hidden email]> wrote:
>>>> I can unify all the message sends to Author in the core image, also I
>>>> can unify the initials and name usage, but
>>>>
>>> It would be nice :)
>>> The prompt should ask for firstname.lastname and not initials :)
>>>
>>>
>>
>> So I can replace all the prompts to initials for name in the format you mention.
>>
>> Will this format be the prefered/oficial one?
>> Will other formats be allowed? Maybe asking for firstname and then for
>> lastname and
>> then inside Author concatenating in a firstname.lastname.
>>
>> What happens with someone with two firstnames and lastnames, like me:
>>
>> Miguel Enrique Cobá Martínez
>>
>> Firstname: Miguel Enrique
>> Lastname: Cobá Martínez
>>
>> yes it is an bad example as I would write:
>>
>> Firstname: Miguel
>> Lastname: Cobá
>>
>> What about spaces?
>>
>
> Spaces aren't avoidable since some names have them e.g. "von Braun".
> Other things to consider are some cultures (like japanese) write names
> lastname, firstname and others have non-letter chars in their names e.g.
> irish names can have apostrophies like "O'Brien" and double barrelled
> names can have dashes.
>
> The best way to do it might be to just have a field for you to input
> your name in your preferred form since proper international name
> handling is complicated.

Yes, I know, my lastname has an acute accent. So then we can, in the
prompt, suggest to not use spaces and to write an ascii aproximation
(until full unicode input it is enabled in the image) of his prefered name
string, e.g.

miguel.coba
MiguelCoba
miguelcoba
MiguelVonCoba
MiguelOBrian
GoeranKrampe
GoranKrampe
YoshikiOshima
etc

Cheers,
Miguel Cobá

>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Miguel Cobá
In reply to this post by Miguel Cobá
On Wed, Jul 22, 2009 at 5:20 PM, Miguel Cobá<[hidden email]> wrote:

> On Wed, Jul 22, 2009 at 4:32 PM, Stéphane
> Ducasse<[hidden email]> wrote:
>>>
>>> Yes but I mean, in a clean core image, on first method save it asks
>>> for the initials,
>>> this is stored on the initials inst var of the singleton Author.
>>>
>>> But on the World Menu, the set author name, it stores (in a
>>> firstname.lastname format) the
>>> value entered in the name inst var
>>>
>>> So, setting one, doesn't set the other.
>>> Also, the messages are different for each one (rightly, because are
>>> different things) but I
>>> want to know what is the inteded behavior from now on to trying to do
>>> the changes.
>>
>> Yes this is the mess.
>> Can you propose a nice solution?
>
> Ok, this is the proposal.
>
> The Author class will use only the name inst var and related methods.
> The initials related are to be unused and later droped in a subsecuent release.
>
> All the calls to initials methods will be replaced by names methods.
>
> The format for the name will be free, and suggested by the prompt message to
>
> firstname.lastname
>
> but not enforced.
>
> It will not allow spaces, just letters and periods in places of spaces e.g.
>
> Miguel Cobá -> miguel.coba
> John The Hacker -> john.the.hacker
> Peter O'Toole -> peter.otoole or maybe peter.o.toole
>
> This period in place of space can be discussed because monticello
> replaces periods for "_".
> Maybe 'firstname_lastname' should be suggested in the prompt.
>
> Every package not in core that use the initial methods should be
> allowed to use the deprecated
> initials methods but strongly urged to change to the names methods.
>
> At least in core, the initials should not be used anymore.
>
> What do you think?
>
> Miguel Cobá
>
>

Something easier would be to write the same to initials and name no matter
what method was called, this would be less disruptive to the image but it
will also have to modify the prompt messages to not mention initials but name
in all messages.

I, personally, vote for the complete delete of initials code mentioned before.

Miguel Cobá

>>
>>> Is the user only asked for name (forcing a format like
>>> firstname.lastname) and the initials
>>> are calculated accordingly?
>>
>> would be good but some people on ss have funky initials because theirs
>> were taken.
>> This is why initials does not scale.
>>
>>> Are the initials doomed to disappear, and the only interface will be
>>> the name (and possibly the
>>> email and other fields mentioned) to identify a person? This means to
>>> modify all the senders to
>>> initial methods and point them to name methods. With the time, the
>>> initials inst var will be droped
>>> from the Author class.
>>
>> I think so.
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

hernanmd
In reply to this post by Alexandre Bergel
You should excuse me. What follows is a combination of wishful thinking and inquiry, and I really don't know if there's place or interest in this kind of discussion here.

An Author should be an object. Right? Because a String or an "annotation" is not the most accurate concept that describes you in the system, and I know smalltalkers which feel a subtle ontological degradation when they realize they are not an object :)

But, what is an Author anyway? It is different from a Mantainer? There are External Contributors? The role plays an important game here. And an Author or Mantainer is not necessarily an individual, it could be even an Institution or Team. Often Institutions, for example, have hierarchical names, historical names, they are joined or splitted, etc. Modelling this set of interactions in an universal way is very complex [*], and there should be a reasonable stopper, which I honestly think, is the most difficult thing to find because requires a lot of experience building systems. I am the only one who think this?

This little issue (not having Authors and friends as objects) prevents doing possibly some pretty cool tools.
-What about finding the role of somebody in a method?
-And what about assessing the author of a class and the maintainer?
-You may want to find the e-mail of somebody (to verify a patch, to ask him something), but is not there.
-Avoiding impersonation when commiting in public repositories?
-You comment a message, compile the method and...magically you're the new "author".
-And could limit the evolution of some research developments like Subjectivity, or reverse engineering tools.

But, I'm lying to you if I advocate such simplistic view. There's no such Author, and in history the authors as we know today are just a constructed figure in Literature after the Renaissance. In fact computer practicioners adopted that word, as many others, as a common practice taking words from other fields, but there's a real challenge in determining the very nature of an Author.  An anonymous method has a writer, but not an author, and one could think the same about auto-generated code. So an author could be a constructed figure out of the writers, and there are other figures not so visible in a first sight. So having a good reification of a Writer, Author, and its roles, bring new possibilities to Smalltalk/Pharo, because the richer your "human model" and vocabulary, the more you can express and think about the continuous, the problem of interpretation and authority, etc.

Cheers

Hernán

[*] We are facing this situation in our FRBRoo model currently.

2009/7/22 Alexandre Bergel <[hidden email]>
> This package, in the last core image is modified but not commited so
> when following the steps
> from the HowToContribute wiki page, in the part of creating a mcz
> package with the change the mcz
> generate will include the other uncommited changes. Should I use a
> changeset instead in order to not
> commit changes that I don't want?

First, you should update your image. It should be a core. Your change
must be produced for Core.
Then, implement your fixe. If more than one package is touched, then
produce a slice. You should save your fix in PharoInbox using
Monticello.
Last step, make sure your fix load in a fresh and updated core image;
add an issue in the google website; send an email to the mailing list.

> What is the goal with the Author class?

A reification of author. Authors should not be strings passed around.



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Damien Cassou
In reply to this post by Stéphane Ducasse
On Wed, Jul 22, 2009 at 9:53 PM, Stéphane
Ducasse<[hidden email]> wrote:
> The prompt should ask for firstname.lastname and not initials :)

please choose FirstnameLastname instead to avoid problems with mcz

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Michael Roberts-2
I made a start on changing this class but didn't finish it. One thing
you should do is separate asking the developer for his name to
encoding it. So there should be a form with multiple input fields.
Then only internally do you apply the convention e.g. _ between
fields. Second the initials string is stored as a string in the
changes file. This is the hardest place to reify it into an object so
I suggest to leave that encoded for the moment. Thirdly you need to
update the versions tools that display this string directly.

Thanks
mike
On Thursday, July 23, 2009, Damien Cassou <[hidden email]> wrote:

> On Wed, Jul 22, 2009 at 9:53 PM, Stéphane
> Ducasse<[hidden email]> wrote:
>> The prompt should ask for firstname.lastname and not initials :)
>
> please choose FirstnameLastname instead to avoid problems with mcz
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Stéphane Ducasse
In reply to this post by Miguel Cobá
I would not add a license on a method level.

Stef

On Jul 22, 2009, at 11:38 PM, Miguel Cobá wrote:

> Also, check this bug in mantis
>
> http://bugs.squeak.org/view.php?id=6993
>
> It can be added to the author class also and unify them in a single  
> place.
>
>
> On Wed, Jul 22, 2009 at 4:35 PM, Miguel Cobá<[hidden email]>  
> wrote:
>> On Wed, Jul 22, 2009 at 2:53 PM, Stéphane
>> Ducasse<[hidden email]> wrote:
>>>>
>>>>
>>>> What is the goal with the Author class? I can see that the  
>>>> Utilities
>>>> methods that used to be use to set
>>>> author name and initials are being replaced with calls to Author.
>>>> Also, they are deprecated in Utilities.
>>>> Questions:
>>>>
>>>> Author has name and initials, what will be the intended use of  
>>>> them?
>>>
>>> We should not use initials.
>>
>> This means that all the methods referencing initials should be
>> replaced with calls
>> to equivalent name methods?
>>
>>> We should not use Utilities in the future.
>>>
>>>> By previous mails in the list I remember
>>>> that Pharo doesn't want to use initials (like mcm, lr, avi) but  
>>>> full
>>>> name as hinted by the message prompt in
>>>> the Author requestName. But then initials will have exactly the  
>>>> same
>>>> that name in the author class?
>>>
>>> It should be cleaned but nobody took the time.
>>>
>>
>> I can do, but I need more directions
>>
>>>> I can unify all the message sends to Author in the core image,  
>>>> also I
>>>> can unify the initials and name usage, but
>>>
>>> It would be nice :)
>>> The prompt should ask for firstname.lastname and not initials :)
>>>
>>
>> So I can replace all the prompts to initials for name in the format  
>> you mention.
>>
>> Will this format be the prefered/oficial one?
>> Will other formats be allowed? Maybe asking for firstname and then  
>> for
>> lastname and
>> then inside Author concatenating in a firstname.lastname.
>>
>> What happens with someone with two firstnames and lastnames, like me:
>>
>> Miguel Enrique Cobá Martínez
>>
>> Firstname: Miguel Enrique
>> Lastname: Cobá Martínez
>>
>> yes it is an bad example as I would write:
>>
>> Firstname: Miguel
>> Lastname: Cobá
>>
>> What about spaces?
>>
>>>> I need to know the intended goal for this class.
>>>>
>>>> What is the goal?
>>>
>>> To represent metadata of the author.
>>> Probably having initial and password for monticello/ squeaksource
>>> makes sense.
>>>
>>>
>>
>> What is the reason to store the password, to automate login to  
>> squeaksource, or
>> something like that?
>>
>> Thanks,
>> Miguel Cobá
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Stéphane Ducasse
In reply to this post by Douglas Brebner
no space  in names
sorry for van Neumann -> vanNeumann

Stef

On Jul 23, 2009, at 12:58 AM, Douglas Brebner wrote:

> Miguel Cobá wrote:
>> On Wed, Jul 22, 2009 at 2:53 PM, Stéphane
>> Ducasse<[hidden email]> wrote:
>>>> I can unify all the message sends to Author in the core image,  
>>>> also I
>>>> can unify the initials and name usage, but
>>>>
>>> It would be nice :)
>>> The prompt should ask for firstname.lastname and not initials :)
>>>
>>>
>>
>> So I can replace all the prompts to initials for name in the format  
>> you mention.
>>
>> Will this format be the prefered/oficial one?
>> Will other formats be allowed? Maybe asking for firstname and then  
>> for
>> lastname and
>> then inside Author concatenating in a firstname.lastname.
>>
>> What happens with someone with two firstnames and lastnames, like me:
>>
>> Miguel Enrique Cobá Martínez
>>
>> Firstname: Miguel Enrique
>> Lastname: Cobá Martínez
>>
>> yes it is an bad example as I would write:
>>
>> Firstname: Miguel
>> Lastname: Cobá
>>
>> What about spaces?
>>
>
> Spaces aren't avoidable since some names have them e.g. "von Braun".
> Other things to consider are some cultures (like japanese) write names
> lastname, firstname and others have non-letter chars in their names  
> e.g.
> irish names can have apostrophies like "O'Brien" and double barrelled
> names can have dashes.
>
> The best way to do it might be to just have a field for you to input
> your name in your preferred form since proper international name
> handling is complicated.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Stéphane Ducasse
In reply to this post by Miguel Cobá

On Jul 23, 2009, at 12:20 AM, Miguel Cobá wrote:

> On Wed, Jul 22, 2009 at 4:32 PM, Stéphane
> Ducasse<[hidden email]> wrote:
>>>
>>> Yes but I mean, in a clean core image, on first method save it asks
>>> for the initials,
>>> this is stored on the initials inst var of the singleton Author.
>>>
>>> But on the World Menu, the set author name, it stores (in a
>>> firstname.lastname format) the
>>> value entered in the name inst var
>>>
>>> So, setting one, doesn't set the other.
>>> Also, the messages are different for each one (rightly, because are
>>> different things) but I
>>> want to know what is the inteded behavior from now on to trying to  
>>> do
>>> the changes.
>>
>> Yes this is the mess.
>> Can you propose a nice solution?
>
> Ok, this is the proposal.
>
> The Author class will use only the name inst var and related methods.
> The initials related are to be unused and later droped in a  
> subsecuent release.
>
> All the calls to initials methods will be replaced by names methods.
>
> The format for the name will be free, and suggested by the prompt  
> message to
>
> firstname.lastname
>
> but not enforced.
>
> It will not allow spaces, just letters and periods in places of  
> spaces e.g.
>
> Miguel Cobá -> miguel.coba
> John The Hacker -> john.the.hacker
> Peter O'Toole -> peter.otoole or maybe peter.o.toole
>
> This period in place of space can be discussed because monticello
> replaces periods for "_".
> Maybe 'firstname_lastname' should be suggested in the prompt.
>
> Every package not in core that use the initial methods should be
> allowed to use the deprecated
> initials methods but strongly urged to change to the names methods.

use deprecated methods for that.

>
> At least in core, the initials should not be used anymore.
>
> What do you think?
>
> Miguel Cobá
>
>
>>
>>> Is the user only asked for name (forcing a format like
>>> firstname.lastname) and the initials
>>> are calculated accordingly?
>>
>> would be good but some people on ss have funky initials because  
>> theirs
>> were taken.
>> This is why initials does not scale.
>>
>>> Are the initials doomed to disappear, and the only interface will be
>>> the name (and possibly the
>>> email and other fields mentioned) to identify a person? This means  
>>> to
>>> modify all the senders to
>>> initial methods and point them to name methods. With the time, the
>>> initials inst var will be droped
>>> from the Author class.
>>
>> I think so.
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Douglas Brebner
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote:
> no space  in names
> sorry for van Neumann -> vanNeumann
>
>  
Also beware of non-letters like - and ' (dash and apostrophe) which can
and do appear.

> On Jul 23, 2009, at 12:58 AM, Douglas Brebner wrote:
>
>  
>> Miguel Cobá wrote:
>>    
>>> On Wed, Jul 22, 2009 at 2:53 PM, Stéphane
>>> Ducasse<[hidden email]> wrote:
>>>      
>>>>> I can unify all the message sends to Author in the core image,  
>>>>> also I
>>>>> can unify the initials and name usage, but
>>>>>
>>>>>          
>>>> It would be nice :)
>>>> The prompt should ask for firstname.lastname and not initials :)
>>>>
>>>>
>>>>        
>>> So I can replace all the prompts to initials for name in the format  
>>> you mention.
>>>
>>> Will this format be the prefered/oficial one?
>>> Will other formats be allowed? Maybe asking for firstname and then  
>>> for
>>> lastname and
>>> then inside Author concatenating in a firstname.lastname.
>>>
>>> What happens with someone with two firstnames and lastnames, like me:
>>>
>>> Miguel Enrique Cobá Martínez
>>>
>>> Firstname: Miguel Enrique
>>> Lastname: Cobá Martínez
>>>
>>> yes it is an bad example as I would write:
>>>
>>> Firstname: Miguel
>>> Lastname: Cobá
>>>
>>> What about spaces?
>>>
>>>      
>> Spaces aren't avoidable since some names have them e.g. "von Braun".
>> Other things to consider are some cultures (like japanese) write names
>> lastname, firstname and others have non-letter chars in their names  
>> e.g.
>> irish names can have apostrophies like "O'Brien" and double barrelled
>> names can have dashes.
>>
>> The best way to do it might be to just have a field for you to input
>> your name in your preferred form since proper international name
>> handling is complicated.
>>
>>    

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Stéphane Ducasse
Yes all that should be filtered :)

Stef

On Jul 23, 2009, at 11:09 AM, Douglas Brebner wrote:

> Stéphane Ducasse wrote:
>> no space  in names
>> sorry for van Neumann -> vanNeumann
>>
>>
> Also beware of non-letters like - and ' (dash and apostrophe) which  
> can
> and do appear.
>> On Jul 23, 2009, at 12:58 AM, Douglas Brebner wrote:
>>
>>
>>> Miguel Cobá wrote:
>>>
>>>> On Wed, Jul 22, 2009 at 2:53 PM, Stéphane
>>>> Ducasse<[hidden email]> wrote:
>>>>
>>>>>> I can unify all the message sends to Author in the core image,
>>>>>> also I
>>>>>> can unify the initials and name usage, but
>>>>>>
>>>>>>
>>>>> It would be nice :)
>>>>> The prompt should ask for firstname.lastname and not initials :)
>>>>>
>>>>>
>>>>>
>>>> So I can replace all the prompts to initials for name in the format
>>>> you mention.
>>>>
>>>> Will this format be the prefered/oficial one?
>>>> Will other formats be allowed? Maybe asking for firstname and then
>>>> for
>>>> lastname and
>>>> then inside Author concatenating in a firstname.lastname.
>>>>
>>>> What happens with someone with two firstnames and lastnames, like  
>>>> me:
>>>>
>>>> Miguel Enrique Cobá Martínez
>>>>
>>>> Firstname: Miguel Enrique
>>>> Lastname: Cobá Martínez
>>>>
>>>> yes it is an bad example as I would write:
>>>>
>>>> Firstname: Miguel
>>>> Lastname: Cobá
>>>>
>>>> What about spaces?
>>>>
>>>>
>>> Spaces aren't avoidable since some names have them e.g. "von Braun".
>>> Other things to consider are some cultures (like japanese) write  
>>> names
>>> lastname, firstname and others have non-letter chars in their names
>>> e.g.
>>> irish names can have apostrophies like "O'Brien" and double  
>>> barrelled
>>> names can have dashes.
>>>
>>> The best way to do it might be to just have a field for you to input
>>> your name in your preferred form since proper international name
>>> handling is complicated.
>>>
>>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Author class

Alexandre Bergel
In reply to this post by Miguel Cobá
> Yes but I mean, in a clean core image, on first method save it asks
> for the initials,
> this is stored on the initials inst var of the singleton Author.

Yes. But better would be to ask for the name of the author instead of  
its initial.

> But on the World Menu, the set author name, it stores (in a
> firstname.lastname format) the
> value entered in the name inst var

It does the right thing.

> Is the user only asked for name (forcing a format like
> firstname.lastname) and the initials
> are calculated accordingly?

initials cannot be calculated for a given name. The domain range of  
initials does not range.
A simple example, the initials I adopted are 'ab'. Avi Bryant uses  
'avi'.

> Are the initials doomed to disappear, and the only interface will be
> the name (and possibly the
> email and other fields mentioned) to identify a person? This means to
> modify all the senders to
> initial methods and point them to name methods. With the time, the
> initials inst var will be droped
> from the Author class.

Probably yes. Another great things will be to store this on the  
filesystem. This is really boring to enter your name each time you  
open a new image.

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12