Hi David,
On 4 June 2018 at 18:07, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, May 17, 2018 at 11:09:59PM -0600, Simon Glass wrote:
>> Hi David,
>>
>> On 13 September 2017 at 06:42, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> > On Thu, Aug 31, 2017 at 04:42:00AM -0600, Simon Glass wrote:
>> >> Extend the Properties class with some functions to read a single integer
>> >> property. Add a new getprop_obj() function to return a Property object
>> >> instead of the raw data.
>> >>
>> >> This suggested approach can be extended to handle other types, as well as
>> >> arrays.
>> >>
>> >> Signed-off-by: Simon Glass <sjg@xxxxxxxxxxxx>
>> >
>> > Sorry again I've taken so long to respond.
>> >
>> > This way of doing it really seems awkward to me. You're introducing a
>> > clunky variant getter just to wrap the bytearray in an object,
>> > essentially just to get conversion methods.
>> >
>> > It seems to be simpler to just have as_cell() and whatnot as plain
>> > functions that go straight from bytestring/bytearray to an int or
>> > whatever.
>>
>> I don't really understand this. Which class would as_cell() be a
>> member of?
>
> None. That's what I mean by "plain function". This is Python, not
> Java, so we're not living in the Kingdom-of-the-Nouns.
>
>> Surely it makes sense for these functions to be members of the
>> Property class, since they act on properties.
>
> Not really, they're equally valid on any bytestring... for example one
> you're building yourself to put into a property but haven't yet.
We end up with:
libfdt.as_uint32(self.get_prop("prop-hex32"))
instead of
self.get_prop("prop-hex32").as_uint32()
I thing the former is shorter and better.
Can you really imagine a situation where you want to call this
function on a property you are building? I rather suspect that people
will use things like setprop_uint32() to set properties directly.
Anyway, I'm going to send v4 with this change (so far as I understand
it) and we'll see how it looks. I do think there is a place for the
functions you want, and we can perhaps consider member functions
later.
[..]
Regards,
Simon
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
