>>
> I have a problem with that; I viewed CRS as setting the internal state,
> and then that internal state would
> be used as each geometry was added.
>
> setCRS( crs ) and crs( crs ) are the same implementation - one supports
> chaining the other does not.
>
> Here is how I always implement chaining:
> void setCRS( CoordinateReferenceSystem crs ){
> this.currentCRS = crs;
> }
> SimpleFeatureBuilder crs( CoordinateReferenceSystem crs ){
> setCRS( crs );
> return this;
> }
>> For instance, until recently feature types themselves had a crs. This
>> has been removed now but the setCRS would map to that crs, the one of
>> the feature type itself. And actually in implementation one thing we
>> might actually want to do is set the crs as user data. By using setCRS
>> to set the global context for each attribute that is added you are
>> clobbering it each time.
>>
>> Is that making sense?
Yes, and you are correct, they are the same. But my point was that if
you look at the example its using global state to set per attribute
state. Its like doing this.
builder.setMinOccurs( 1 );
builder.add( "foo", Foo.class );
builder.setMinOccurs( 2 );
builder.add( "bar", Bar.class );
The following just seems more direct to me:
builder.minOccurs( 1 ).add(...);
builder.minOccurs( 0 ).add( ...);
There is also another subtly here. If you use the first example, the
"default" for subsequent values is not the sensible default anymore, it
was the last value you set.
So if I were to add a third attribute:
builder.add( "foobar", FooBar.class );
It has a minOccurs of 2, even thought eh user did not specify. I would
think that it should be 1, the sensible default.
Not sure i am explaining this very well...
>>
> Yes it does; I thought you were removing Feature.getCRS() as not required?
I did, hense the word "had" :). I was just using it an example.
>
>> I also think that in the first example, the "chaining" alternative
>> should be removed. The intent of chaining is to provide a nice way to
>> differentiate between global and per attribute state, not to make the
>> code sample less lines of code. So I suggest we remove it as its just
>> one less thing for the user to see, and stick to using chaining where
>> there is an actual need for it.
>>
> I have the second viewpoint.
>> Also... keep on thing in mind. That document is not intended for users
>> at this time. It is intended for other geotools developers at the code
>> sprint. So I am not worried about getting it absolutely right at this time.
>>
> I second that - we should let hand on experience guide this document;
> otherwise we will end up with methods
> that we don't end up using.
> Jody
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
> !DSPAM:4007,46f2a40a136182143011171!
>
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
