Hello!
I think we should check that setField happily accepts both BinaryObject and
BinaryObjectBuilder, and then deprecate this method.
Regards,
--
Ilya Kasnacheev
пт, 6 дек. 2019 г. в 16:02, Alexei Scherbakov :
> Looks like it's already possible to pass binary object as value using
> BinaryO
Looks like it's already possible to pass binary object as value using
BinaryObjectBuilder setField(String name, Object val);
If it works we can remove a signature with BinaryObjectBuilder.
The API is truly confusing.
пт, 6 дек. 2019 г. в 15:55, Николай Ижиков :
> I’m too, Alex.
>
> But, this si
I’m too, Alex.
But, this signature leads to the same error as I mentioned.
> 6 дек. 2019 г., в 15:53, Alexei Scherbakov
> написал(а):
>
> I wonder why signature is not
>
> setField(String name, BinaryObject obj)
>
> пт, 6 дек. 2019 г. в 15:00, Ilya Kasnacheev :
>
>> Hello!
>>
>> I think
I wonder why signature is not
setField(String name, BinaryObject obj)
пт, 6 дек. 2019 г. в 15:00, Ilya Kasnacheev :
> Hello!
>
> I think that repeating argument type name in method name is a code smell.
> Rather, we should describe how this method is different from other methods
> of its bunch.
Hello!
I think that repeating argument type name in method name is a code smell.
Rather, we should describe how this method is different from other methods
of its bunch.
In this case, it is different since it allows you to create nested binary
objects, i.e., ones with non-flat structure.
Regards
Hello, Ilya.
I don’t get your point
> We don’t passing … binary, just a … BinaryObjeсtBuilder.
May be we should go with `setBinaryObjectBuilderField` or
`setBinaryObjectField`?
> 6 дек. 2019 г., в 13:38, Ilya Kasnacheev
> написал(а):
>
> Hello!
>
> I can see where you are getting at, can
Hello!
I can see where you are getting at, can we call it "setFieldNested" instead
or something like that?
setBinaryField is confusing because we're not passing anything especially
binary, just a nested BinaryObjectBuilder.
Regards,
--
Ilya Kasnacheev
пт, 6 дек. 2019 г. в 13:17, Николай Ижико
Nikolay,
It seems to me, that the real cause of the issue is a contract:
public T getField(String name);
Which can lead to class cast to any type. Consequently, a user gets
runtime type checks instead of compile time checks.
On the other hand, your proposal could be handy in practice, have
not
Hello, Igniters.
We have confusing API in `BinaryObjectBuilder` class.
The code below leads to the `ClassCastException`
The cause is java method resolution rules [1]
> There may be more than one such method, in which case the most specific one
> is chosen
I suggest to deprecate `setField(Strin
