Hi David,
On 9 June 2018 at 01:09, David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Jun 06, 2018 at 11:59:26AM -0800, Simon Glass wrote:
>> 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.
>
> Erm.. I'm guessing you meant to say you think the latter is shorter
> and better.
Yes, that's right, sorry.
>
>> 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.
>
> I can.. but then I can imagine a lot of things.
Well maybe we should see how things go and worry about the class members later.
>
>> 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
