[Rbrainz-users] Do you need help.

Nigel Graham nigel at maven-group.org
Wed Jun 13 05:56:05 EDT 2007


Philipp Wolfer wrote:
> 2007/6/7, Nigel Graham <nigel at maven-group.org>:
>   
>> As I mentioned earlier I am not such a big fan of using tests on the
>> class type. I have attached a duck typing edition of MBID for you to
>> look at and comment on.
>>     
> I'm still not completely used to "messing around in foreign
> namespaces", butI like your implementation very much. It cleanly
> solves the requirement to allow strings (or other representations of
> the ID) wherever it is convenient.
>
> I have a few comments about the various methods: We won't need
> "from_string" anymore, it is conceptual the same as "parse", which I
> like better. And I'm not sure about "from_uuid" and "from_uri"
> anymore. My original idea was to make it explicit what you are doing.
> But in many cases you don't know what you have anyway and you end up
> using "parse". So we could get rid of those two methods as well. Or
> maybe we could even offer only "new". What do you think?
>
> What I liked about the old code was the fact that the two use cases
> creating a MBID from an URI or a UUID were logical divided, now it's
> all in one method (initialize). Maybe we could split it up internally
> (from_uuid, from_uri, but private).
>   
I have thought about it and I think that we should get rid of from_uri 
and from_uuid.
The justification is that I think it's the most Ruby'esc approach and 
the one that most follows the paradigm of duck typing.
What I mean by that is that it does a best effort to convert any 
argument into an MB ID.
The only counter argument I could come up with was that the 
differentiation between the two use cases you describe is necessary to 
make a strict parser of some kind.

> One quick note about code style: I don't like long lines (I set the
> limit to 80 characters per line), so I normally use the post "if" or
> "unless" only in very short statements, even if the alternative uses 3
> lines.
>
>   
Good point. I have changed the code I sent you to only use post "if" and 
"unless" when the line is shorter than 80 characters.
>> Based on previous experience with incomplete/partial dates I have found
>> it usefull to consider them as time periods. This way of looking at them
>> considerably lightens the burden of dealing with them with regards to
>> other data types like Time and Date. Another advantage is that periods
>> have a string of well defined operations that makes it so much easier to
>> to do stuff like finding bands that were active from 1979 - 1999.
>>     
> I'm not sure if I get your point here. Would it mean to store a begin
> and end date, e.g. "1988-08-01" and "1988-08-31" for the incomplete
> date "1988-08"?
> As far as I understand this is mainly a comparison problem. Isn't this
> basically solved by the current implementation of <=>?
>
>   
I will try and explain it better. The problem is both one of comparison 
and of associations brought by the name.
When you call something an incomplete date the expectation is for it to 
be a special kind of date. A date that is from a usability perspective a 
very good idea.

The problem from a developer perspective is that you can't get it to act 
like a date. Mostly when dealing with comparisons.
What I will try an convince you of is that an incomplete date is in fact 
a special kind of time period.

Normal dates have the standard 3 comparisons; after / greater than, 
before / less than and equality.
They suit all your needs and follow the rules of transitivity.
For time periods and indeed incomplete dates these 3 operations aren't 
that useful (not if they are transitive).
Instead time periods have 4 additional comparisons; starts, ends, 
overlaps and between.

Your current implementation of <=> while not transitive works for a lot 
of use cases. But it is confusing to be using a <=> comparison to find 
what would be the following operation were it periods: a between b && b 
between a
A case where it fails is:
Given an array of release events, reX, find all release events that did 
not occur on 1979-03-15.
reX.find_all{|e| e != IncompleteDate.new('1979-03-15')} # Wrong! What 
about incomplete date 1979??

What I am proposing is that we make IncompleteDate act as a period with 
at least the 7 operations and get rid of the ordering operator (<=>) 
since periods have no default ordering that makes much sense.
That way it is up to the user of the gem to decide which comparison he 
wants to use.

>> Another problem is that Gem::Platform doesn't reflect this 3 binary
>> system. Gem::Platform::DARWIN contains the string 'powerpc-darwin' which
>> is only the right value for PowerPC binaries.
>>     
> That's a problem. Do you know how other projects solve this?
>   
I think they simply don't distribute binary gems. Another problem with 
binary gems that depend on 3rd party libraries is that the library 
contains the path of the 3rd party library it depends on. On a mac this 
path is different depending on how you installed the 3rd party library. 
MacPorts install in /opt/local/lib and locally compiled binaries usually 
get installed in /usr/local/lib.
> If you have a Rubyforge login I would like to give you access to the
> project's SVN repository. You could checkin your MBID changes and
> integrate them properly. In the week beginning on June 25th we could
> then talk about our further project plans in detail and have a little
> chat about ourselves.
>   
My login is nigel_graham.
And I'm looking forward to a more in-depth talk.

Mvh.
Nigel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nigel.vcf
Type: text/x-vcard
Size: 163 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rbrainz-users/attachments/20070613/34a6c59e/attachment.vcf 


More information about the Rbrainz-users mailing list