referencing columns

[Douglas Surber]

I will say I’m not at all sure what Column.spliterator() has to do. That will take some investigation. My guess is that it will create clones or slices.

Douglas

> On May 4, 2018, at 8:39 AM, Douglas Surber <douglas.surber at oracle.com> wrote:
> 
> Your alternative does not include the motion methods directly. In order to get to next the app would have to call iterator. Having gotten an iterator so it can call next it cannot get back to Row.
> 
> Note that Column is mutable and all of the methods mutate the Column except clone and slice. In your example I would expect columns == c1 == c2 == c3. As such when for (Column c3 : c2) completes c3.hasNext() is false hence the same for c2 and c1 and all of the loops would exit.
> 
> I agree this is a bit odd. What it is doing is getting Iterator and Interable to fit the fluid style. And so far it seems to work. No doubt you can write some odd things, but with a little care in the spec I think it would all be well and simply defined. The thing that makes it work is that, except for slice and clone, there is only one Column and every motion method changes which value it points to.
> 
> Now it would be reasonable to say that the argument passed to Iterable.forEach is a clone of the Column. That would make your nested for loops do a triangle iteration. I think this adds unnecessary complexity. If that’s what the user wants it is easy enough to write
> 
>  for (Column c1 : columns.clone())
>    for (Column c2 : c1.clone())
>      for (Column c3 : c2.clone())
> 
> If forEach (and possibly other methods) create clones understanding what this all does becomes more complex. If there is only one mutable Column then I think everything is easy to understand; only one rule to follow.
> 
> The more I play with this the more I like it. I’d like to hear from the other people on the list before I make the change to ADBA.
> 
> Douglas
> 
>> On May 4, 2018, at 8:13 AM, Lukas Eder <lukas.eder at gmail.com <mailto:lukas.eder at gmail.com>> wrote:
>> 
>> Well, I'm mentioning this because I've never seen a type T extends Iterable<T>. It sounds weird and intriguing, but that's not always a good thing :). It would allow for things like:
>> 
>> for (Column c1 : columns)
>>  for (Column c2 : c1)
>>    for (Column c3 : c2)
>>      ; // What do these even mean?
>> 
>> In your alternative design, ColumnIterator and ColumnCursor don't seem strictly necessary. This would suffice:
>> 
>> public interface Row extends Iterable<Column>{
>>  public long rowNumber();
>>  public Row cancel();
>>  public Column at(String id);
>>  public Column at(int index);
>>  // forEach, iterator, spliterator
>> }
>> 
>> public interface Column {
>>  public <T> T get(Class<T> type);
>>  public SqlType sqlType();
>>  public <T> Class<T> javaType();
>>  public String id();
>>  public int index();
>> }
>> 
>> 
>> 2018-05-04 16:28 GMT+02:00 Douglas Surber <douglas.surber at oracle.com <mailto:douglas.surber at oracle.com> <mailto:douglas.surber at oracle.com <mailto:douglas.surber at oracle.com>>>:
>> I encourage you to actually write some code using both and see what you think.
>> 
>> I will definitely do things like in the beginning of this email, trying to "break" the API :)