Re: [Rails-devel] Updated rails 2.0 branch

[brett l. <bre...@gm...>]

On Mon, Jun 11, 2012 at 3:20 PM, Erik Vos <eri...@xs...> wrote:
> Stefan,
>
> Strange things sometimes happen: your response ended up in my junk mail, and
> I just found it.
>
> I sent my question off-list because I was just curious about the reason why
> you renamed Round to AbstractRound.  I had intended to reserve expressing my
> dislike of that change for a follow-up, if still relevant at all.  But you
> guessed it.  I don't see why the fact that a superclass is abstract should
> be expressed in its name.  If a developer working on a subclass forgets
> that, he'll find out soon enough.  But it's probably just a matter of taste
> - as always.

The one case where I could see this making sense is if we want the
base non-abstract class to be called Round. In that case, we can't
have an abstract class called Round, too. So, calling it
"AbstractRound" or "aRound" or "RoundA" or whatever makes some sense.

Then you have "class Round implements AbstractRound {}" despite also
having the very redundant "abstract class AbstractRound {}".

However, if all of our non-abstract classes are FooRound and BarRound,
then having the abstract class be Round is fine.

>
> On interfaces: I don't like the 'I' postfix either.
> When we started Rails, some people gave their well-meant advices, and I did
> not have much background in Java design, so I went ahead as they told me.
> But here I am on your side.  All or most 'I' interfaces we have are useless
> (in fact: annoying), and if you want to get rid of these, you have my full
> support.
>

+1

This one's my fault. I was also new to Java when I started this
project. So, I was using what I was told were "good" java conventions.
Now that I've done a few more projects in a variety of languages, I
find that I was misusing the convention.

Having interfaces is good if we expose an API, but most of the current
interfaces in the Rails code really aren't useful in that sense. Let's
toss them and, at some future point, we can revisit the issue of what
classes and methods should be a part of a public API and what stuff
ought to be private/protected.

> Erik.
>

---Brett.

>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Monday, May 28, 2012 5:14 PM
>> To: Erik Vos
>> Subject: Re: [Rails-devel] Updated rails 2.0 branch
>>
>> Follow-up:
>> I do not mind to make such discussions on-list, as this can help to
> generate a
>> list of coding standards for Rails.
>> But that is up to you to decide (I did not even imagined to be this
> off-list, but
>> I wondered why it did not came back from the list ...) Stefan
>>
>>
>> Erik:
>> Rails2.0 should not be "my" project, even if I am the driving force
>> behind the refactoring.
>>
>> Good to see your comments:
>>
>> Naming is convention, and mostly a matter of taste. First of all I do
>> not like the postfix -I convention.
>>
>> My preference for Interface names are to either use adjectives, for
>> example Ownable, Observable etc.
>>
>> If I realize that most classes that are derived from an Interface uses
>> the same base implementation I use an abstract Class and prefer a short
>> noun like State, Model etc.
>>
>> If I do not come up with a good adjective for the Interface I use a
>> short noun there (like Item instead of "Itemizeable" or "Roundable") and
>> if I now add a baseline abstract class I prefix with Abstract (e.g.
>> AbstractItem and AbstractRound).
>>
>> However if every class that implements the Interface is derived from the
>> abstract class there is no need to keep the Interface and I drop it, as
>> it is easy to factor it out again later on - if needed.
>>
>> I could have removed the Round interface altogether and rename
>> AbstractRound to Round again, but I did not focus on that so far, as I
>> intend to change the Round mechanism anyway.
>>
>> But if you prefer to keep at least RoundI as historical artifact, this
>> is possible.
>>
>> Stefan
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel