Open discussion on Lift Name Calling practices

[Jim Barrows]

Lift is getting very large.  We've got singular names as lists, and plural names that aren't lists.  We've got people calling roses red flowers, spades diamonds and other mass chaos.  Well, it's not that bad, but you get the idea.  This is an attempt to come up with a series of standard names to make working in lift easier, not only for the committers, but also (and more importantly) for you folks using it on a day to day basis.

Achieving this means that there must be two things, a set of rules for naming conventions, and a process to make sure everyone is following those rules, and changing things when we mess it up.

This thread is for discussing the process.  I'll be starting another thread to discuss the rules, as well as another thread to discuss current names that we want to change.
As always, if you don't speak up, you're not dissenting, and we welcome your views and ideas on how to do this!

1) Goal discussion (closes 8 Dec 09)
2) Identify changes, and put the list on the wiki (closes 15 Jan 10)
3) Convert the list to github tickets.  This includes discussing setting priorities etc, assessing impacts etc etc to go into the ticket. (closes 29 Jan 10)
4) Committers can then work the tickets into their own workflows, and everything would then follow the normal commit workflow from there. (committers work according to priority and impact etc)
5) Naming becomes a part of the normal review board process.  However, if a committer thinks that the Name Caller needs to look at it earlier, or is having a hard time with naming something, by all means send an email.  ( date we add this to the process 29 Jan 10)
6) As we find things we missed, or better names, we work them through the github ticket and review system. ( date we add this to the process 29 Jan 10)

--
James A Barrows

[David Pollak]

Jim,

Thanks for spearheading this effort!

Let's do what we can to give Jim feedback on the timeline and then get the ball rolling.

Thanks,

David

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[Kris Nuttycombe]

The timeline looks good to me, with the exception of the fact that
we've already passed the first milestone!

With respect to goals, I have a few general suggestions.

1) Remove ambiguity wherever possible! There are a number of places
where very similar names are used to refer to utterly different
things.
2) As an aide removing ambiguity, consider outlawing or eliminating
extremely generic names, or else establish a single way in which a
given name will be used across Lift. Examples are Field, Info, Holder,
etc.
3) Avoid making the name of the return type part of the name of the
method. The types should tell the story as much as possible, except in
the case where multiple methods varying only in return type would
exist (illegal overloads)
4) Prefer Scala-style accessors and mutators.

I also am attaching a start at some names I see as suboptimal from
S.scala, but since this thread isn't really for discussion of
individual naming issues (and such a thread doesn't yet exist) I
thought I'd go ahead and present my suggestions as a strawman for
format and what type of changes might be considered.

Kris

[Jim Barrows]

Dates have changed below.  I slipped everything a week.

On Wed, Dec 9, 2009 at 11:59 PM, Kris Nuttycombe <kris.nu...@gmail.com> wrote:

On Tue, Dec 1, 2009 at 1:43 PM, Jim Barrows <jim.b...@gmail.com> wrote:
> Lift is getting very large.  We've got singular names as lists, and plural
> names that aren't lists.  We've got people calling roses red flowers, spades
> diamonds and other mass chaos.  Well, it's not that bad, but you get the
> idea.  This is an attempt to come up with a series of standard names to make
> working in lift easier, not only for the committers, but also (and more
> importantly) for you folks using it on a day to day basis.
>
> Achieving this means that there must be two things, a set of rules for
> naming conventions, and a process to make sure everyone is following those
> rules, and changing things when we mess it up.
>
> This thread is for discussing the process.  I'll be starting another thread
> to discuss the rules, as well as another thread to discuss current names
> that we want to change.
> As always, if you don't speak up, you're not dissenting, and we welcome your
> views and ideas on how to do this!
>

> 1) Goal discussion (closes 15 Dec 09)
> 2) Identify changes, and put the list on the wiki (closes 22 Jan 10)

> 3) Convert the list to github tickets.  This includes discussing setting

> priorities etc, assessing impacts etc etc to go into the ticket. (closes 5

> Jan 10)
> 4) Committers can then work the tickets into their own workflows, and
> everything would then follow the normal commit workflow from there.
> (committers work according to priority and impact etc)
> 5) Naming becomes a part of the normal review board process.  However, if a
> committer thinks that the Name Caller needs to look at it earlier, or is
> having a hard time with naming something, by all means send an email.  (

> date we add this to the process 5 Feb 10)

> 6) As we find things we missed, or better names, we work them through the

> github ticket and review system. ( date we add this to the process 5 Feb

> 10)
>
> --
> James A Barrows

The timeline looks good to me, with the exception of the fact that
we've already passed the first milestone! 

With respect to goals, I have a few general suggestions.

1) Remove ambiguity wherever possible! There are a number of places
where very similar names are used to refer to utterly different
things.
2) As an aide removing ambiguity, consider outlawing or eliminating
extremely generic names, or else establish a single way in which a
given name will be used across Lift. Examples are Field, Info, Holder,
etc.
3) Avoid making the name of the return type part of the name of the
method. The types should tell the story as much as possible, except in
the case where multiple methods varying only in return type would
exist (illegal overloads)
4) Prefer Scala-style accessors and mutators.

I also am attaching a start at some names I see as suboptimal from
S.scala, but since this thread isn't really for discussion of
individual naming issues (and such a thread doesn't yet exist) I
thought I'd go ahead and present my suggestions as a strawman for
format and what type of changes might be considered.

Kris

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
James A Barrows