On keeping 'name': sure, I don't mind being conservative. I would like to keep name in the form on NamedVector. As it happens, name is actually barely used right now -- if you can wade through the patch you can see there's just a few instances, the ones in mind now.
Making NamedVector is, it seems, at worst a waste of time since it may be scrapped. It's my time so waste so I don't mind. I can also see that it's conceivable that a vector name would be used, whether or not it is now. But it is used now, just a little, even if we're saying that could be 'fixed'. What's the issue with reducers dealing with NamedVector? They either need named vectors conceptually, or don't. Right now that difference happens to be hidden; if you send unnamed vectors into such a reducer it'll fail at runtime. This at least promotes that contract to compile-time checking which seems like a good thing. Am I convincing? On Sun, Apr 18, 2010 at 6:45 PM, Jake Mannix <jake.man...@gmail.com> wrote: > Ok this is a good concrete example, I like concrete. :) > > I'm still very wary of having to have some mapper or reducer classes deal > with LabeledVector some deal with just Vector... > > Maybe the right thing to do for now is keep the name in Vector directly, but > fix the serialization which currently can't distinguish between "" and null > properly. > > When we get avro in, maybe it will show the way to nicely handle this kind > of typesafe way of dealing with optional data. > > -jake
