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. > You seem to be suggesting that we have things like: > > def as_cell(self, nodeoffset, prop_name, quiet=()) > > so as to bypass the concept of a Property. We already have the > Property object and I created it specifically to encapsulate a > device-tree property. To me this is preferable to adding lots of > property-access methods to the Fdt class. > > I suppose you could argue that each property probably only gets used > once, so we end up with: > > getprop_obj(nodeoffset, prop_name).as_int32() > > but that still seems better to me than: > > as_int32(nodeoffset, prop_name) > > > > > > > Longer term, I did have an idea that might resolve the > > propery-as-object or property-as-bytestring conundrum a bit more > > satisfactorily. But, I'm not entirely sure how you'd go about > > implementing it with swig in the picture: it should be possible in > > (modern) Python to make a Property object that's a sub-class of the > > (byte)string type. That way it can be used directly as though it were > > a bytestring, but you can also add properties to do extra stuff. > > Yes good idea. I'll add a patch for that. > > > > > [Which raises a minor detail, most of the functions which return > > bytearray()s now should probably be returning strings - there doesn't > > seem to be a reason to return a mutable object] > > I added a patch for the one I found. The way SWIG is set up I have to > pass bytearrays to the libfdt functions though. > > [...] > > Regards, > Simon -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
