:'-( i really don't want to get into another one of these "what
exactly does a term mean and does it apply absolutely and completely
in this scenario". I'm making it a rule from now on that I'm only
going to subject myself to them when alcohol is available.

Hows about, for now, you define it in a way that works for you, I'll
define it in a way that works for me, we agree to agree on most of the
details and agree to differ some of the details.

Next time you're in Dublin give me a call, we can have a pint or ten,
sit down as men do and discuss important things (like the nature of
DRYness).

On Jan 15, 8:22 pm, Sam Smoot <[email protected]> wrote:
> On Jan 15, 1:27 pm, heda <[email protected]> wrote:
>
> > =begin semi-counter rant
>
> > dry-ness to me is the ability to express a concept which is common
> > between various parts via a single point, in some cases that means a
> > constant, in many other its does not
>
> > i agree its not about minimizing keystrokes, i agree it is about
> > maintaining clarity of code and improving the concesity of conceptual
> > expression
>
> > =end
>
> :-)
>
> I think you undermine your argument with your last statement though.
> What concept are you trying to express? What conceptual (and
> importantly, Business Domain) allegiance do first_name, last_name and
> minimum fields share?
>
> When "The Pragmatic Programmer" came out, C, Java and Visual Basic
> dominated. Java without closures. Visual Basic with very rudimentary
> support for inheritance or classes. Only C macros could come close to
> the sort of constructs now commonly presented in Ruby as measures to
> ensure DRYness.
>
> I think it's a lot easier to frame the definition in the context of
> it's time: A developer using Java servlets or an ASP developer, and
> what sorts of things they might have been doing that prompted the
> advice.
>
> It really comes down to this: Without a unifying concept of the
> knowledge you're trying to canonically represent, you can't claim
> DRYness. A default of 50 characters for both a first_name and a
> last_name is not domain knowledge. Odds are, as the domain is refined
> it's seems likely the with_options helper would need to be removed
> down the line so each piece of knowledge can be represented
> accurately.
>
> Enough with my hijacking. ;-) But yeah, I don't have much community
> experience outside of Ruby these days, but it's my impression the
> repurposing of "DRY" is a Rails influenced concept, and it's
> unfortunate that the valuable Domain Knowledge discussion seems mostly
> lost in the superficial and low-value (as far as productivity,
> maintainability, business-value) concept of beauty over Design.
>
> It's a distraction that encourages a race-to-the-bottom that
> emphasizes style over substance; where Domain Driven Design (DDD, the
> first/true one, not the silly development methodology discussion aka
> "d3") is an after-thought. It's a road leads to Ruby as the next big
> Cold Fusion instead of the next big Java (IMO).
>
> -Sam
>
> PS: Yeah... uh... sorry for the de-rail.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"DataMapper" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/datamapper?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to