Re: [smila-dev] new datamodel : Id got replaced by String

[Juergen Schumacher <juergen.schumacher@xxxxxxxxxxxxx>]

Hi,

Am Montag, den 28.03.2011, 12:44 +0200 schrieb Thomas Menzel:
> hi,
> 
> I have noticed that the new model removed the Id Interface and replaced it with String.
> 
> While I understand the motivation to make things simpler and acknowledge that Strings are the most common form of ids in use, I would have highly recommended to stick to an Id Interface, having the gut feeling that we would have been better off doing so. but maybe it's not too late...
> 
> These 2 advantages come to my mind:
> 
> 1. the code/API becomes more verbose. 
> just looking at the type u know what it is used for. this is tremendously helpful in maps, e.g.:
> 
> - Map<String, String> could be meaning: Map<Id, String> or Map<String, Id>
> - process(Blackboard blackboard, String[] recordIds) vs. delete(Blackboard blackboard, Id[] recordIds)
> 
> 2. Being able to provide own impl. against an Id Interface might be very useful in certain circumstances and alleviates to need for help classes to construct proper String from a richer Object.
> 
> proposal
> 
> declare an interface: Id extends CharSequence.
> 
> ATM I don't see a need for more methods than what the CharSeq provides. The internal default impl. could use Strings.

The short answer first: My vote is a -1.

The longer answer: I'm not so fond of this proposal. I acknowledge that
there is a small advantage to have a class Id in declarations like
Map<Id, String>. In the process-signature the advantage is smaller,
because there is the parameter name "recordIds" which clearly tells us
what kind of string to expect.

For now an Id is just a string and I don't see an advantage to pretend
that it could be something else or a special type of string or whatever.
It's a bit like working with C++ code, where you often have to wade
through cascades of typedefs to see what you can do with a variable,
just to recognize in the end that it's just a simple
std::array<std::string>. Only that in this case it would be "something
like a string, but not exactly one." (-;

Requiring the get/setId methods to use "Id"s would also mean to have to
create an additional object in each call when in the end all I need is
just the string. 

And finally, one can still use helper code if the application really
needs to impose some semantics on the ID string (which, btw, is
something I'm not fond of, too. Use attributes to carry meaningful data.
The Id is just an identifier. Could be a UUID.). For an integrator it
would be easier to implement this in helper classes than having to
modify the framework by switching to another Id implementation.

Just my 2ct.

Cheers,
Juergen.