S.Isaac Dealey wrote:
>>S.Isaac Dealey wrote:
>>
>>If you were to ask a linguist if there was inconsistency
>>here, they'd definitely say "no".
>
> You can't remove the argument from its context (programming syntax)
> and expect the argument to continue to be valid. It might but that
> would be a non-sequitur.
Names have zilch to do with program syntax. My argument stands.
>>It's rather simple, and doesn't require a special rule, at
>>least not for
>>native germanic words (and a good deal of the romance ones
>>and others in
>>the language, spare the odd irregular ones like "oxen",
>>"children", and
>>the strong nouns). If a world ends in a sibilant (s, z,
>>sh, x [really
>>"ks"], ch [really "tsh"]); the soft "g" is also a
>>sibilant, but owing to
>>other complications doesn't really figure in this), -es is
>>used. If it
>>ends in -y, -ies is used. Otherwise -s. It's quite simple.
>
> For a human being, yes. But it's not simple to create an automated,
> mechanical means of pluralising words in english. If I wanted to
> automate the relationship between my CFC class names and my tables and
> I used singular class names and plural table names, how would you
> write this function:
>
> function makePlural(noun) { ... }
>
> With the assumption that the function _must_ accept any noun in the
> Oxfard English dictionary.
Hmm... seems you're talking about O-R mapping, aren't you? Sorry, but
that's just not something I've ever bought into.
>>Irregular nouns. Give us a break!
>
> And a synonym of irregular is ... wait for it ... "inconsistent".
And they're also uncommon, and slowly fading away.
>>This goidelophone wishes to disagree.
>
> That's because this goidelophone isn't a stupid computer... A stupid
> computer doesn't know better. A stupid computer would say it's
> inconsistent.
A goidelophone is a gaelic speaker.
What does this have to do with computers? There was me thinking the
primary audience for the code I write is whoever maintains it.
>>>>But when it comes down to it, this is all convention. I
>>>>pluralise
>>>>because bits of SQL like "SELECT ... FROM products ...",
>>>>"INSERT INTO
>>>>products ...", "UPDATE products ...", and "DELETE FROM
>>>>products ..."
>>>>read better than me because these work on sets of
>>>>entities as opposed
>>>>to singular entities. When it comes down to it, how it
>>>>"sounds" is
>>>>really the only way of justifying it.
>>>
>>>It's not the only reason, but it's the reason most
>>>commonly
>>>understood. (Re: previous post regarding automation of
>>>table names).
>
>>And we write code for humans to understand, not computers.
>
> Imo it's no harder (for a human) to understand and write code against
> a singular noun than it is to write it against a plural noun,
> regardless of the context.
I'm not saying it's harder, just that the code reads more awkwardly.
> But personally, I like to reduce my
> workload -- reducing my workload means automating tasks (which in turn
> means reducing or eliminating inconsistencies) -- if a task can be
> automated easily with one syntactical mechanism and not with another,
> I'm going to weigh that in favor of the syntax which can be easily
> automated. I may not ultimately choose that syntax, but it's a
> significant factor.
But this isn't syntax: it's a convention or better still, a notation.
But it definitely ain't syntax.
I pluralise because it allows me to spot collections when I'm scanning
code more easily. Think of it as a sane variant on Hungarian Notation,
if you will. This reduces my workload, because I can quickly spot when
I'm dealing with collections of objects or single objects. If I didn't
pluralise, a name like "doctor" would be ambiguous: is it a bunch of
doctors or a single doctor?
>>>Really if you want to run the length of the argument then
>>>you could
>>>just as easily name your classes plural as well, and
>>>technically a
>>>class does describe a collection of objects (their type),
>>>though when
>>>we write code we don't generally think of a class that
>>>way, we think
>>>of it as being singular even though we then instantiate
>>>objects to
>>>create what are actually singular entities of type.
>>
>>A class is not a collection of objects. A class is is a
>>description of a type of object. Table != class. That's
>>a red herring.
>
> A table describes it's contents by it's properties (columns) and their
> types. A class describes the objects which belong to the class by its
> properties and their types.
A table is a description and a collection, but lacks operations, whereas
a class is just a description and a set of operations, but it is not a
collection. This is why they are not equivalent.
> True, a table doesn't have methods, and we
> generally think of it as being a container, but ultimately either a
> table or a class is a set of meta-data which describes, structures and
> manages many individual items (records or object instances). No a
> table is not a class -- but the argument can be made that they are
> both sub-classes of the same structural concept (with different
> interfaces and/or overloaded methods).
The important point here is that a table is a container/collection,
whereas a class is not (at least not in that sense).
K.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:200985
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
