[Pharo-project] Author class
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á
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Wed, Jul 22, 2009 at 2:25 PM, Alexandre Bergel<alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
On Wed, Jul 22, 2009 at 4:32 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Jul 22, 2009 at 5:20 PM, Miguel Cobá<miguel.coba@gmail.com> wrote:
On Wed, Jul 22, 2009 at 4:32 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I, personally, vote for the complete delete of initials code mentioned before.
+1 Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 23, 2009, at 12:20 AM, Miguel Cobá wrote:
On Wed, Jul 22, 2009 at 4:32 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 <alexandre@bergel.eu>
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.
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.
On Wed, Jul 22, 2009 at 2:53 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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á<miguel.coba@gmail.com> wrote:
On Wed, Jul 22, 2009 at 2:53 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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á<miguel.coba@gmail.com> wrote:
On Wed, Jul 22, 2009 at 2:53 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Miguel Cobá wrote:
On Wed, Jul 22, 2009 at 2:53 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> 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.
On Wed, Jul 22, 2009 at 5:58 PM, Douglas Brebner<squeaklists@fang.demon.co.uk> wrote:
Miguel Cobá wrote:
On Wed, Jul 22, 2009 at 2:53 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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<stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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<stephane.ducasse@inria.fr> 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 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<stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Jul 22, 2009 at 9:53 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> 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
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 <damien.cassou@gmail.com> wrote:
On Wed, Jul 22, 2009 at 9:53 PM, Stéphane Ducasse<stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Alexandre Bergel -
Damien Cassou -
Douglas Brebner -
Hernán Morales Durand -
Michael Roberts -
Miguel Cobá -
Stéphane Ducasse