Author class
Locked
12
12
 
|
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 |
|
|
> 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 |
|
|
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 |
|
|
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. > 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 |
|
|
>
> 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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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]>
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |