[Microbit-Python] Accessor API design on the micro:bit

[Mark Shannon]

On 01/11/15 14:27, Nicholas H.Tollervey wrote:
> This also makes me wonder about descriptor v accessor in other parts of
> the API. For example, could we do this?
>
>>>> microbit.pin0  # digital read
> 1

We could, but we shouldn't.
microbit.pin0 should be a pin, as it is as at the moment.
 >>> microbit.pin0
<MicroBitPin ...>

>>>> microbit.pin0  # analog read
> 234
>>>> microbit.pin0 = 0  # digital set
>>>> microbit.pin0 = 234  # analog set (0...255)

Again no. Normal assignment rules for an attribute should apply.
 >>> microbit.pin0 = "Hello"
 >>> microbit.pin0
"Hello"

Plus, we would have to change microbit from a module to an instance of a 
custom class, in order to support descriptors.

If we really want to use properties for pins then it should be:
microbit.pin0.digital(_value)
and
microbit.pin0.analog(_value)

But I prefer the read()/write() methods.

For the accelerometer, there is no digital/analog state change, and you 
cannot write to it. So accelerometer.x seems consistent with "x" 
appearing to be a simple attribute of the accelerometer object.

IMO, descriptors should generally appear to have the same interface as 
simple object attributes, even if they are "special" under the covers.

>
> Not sure whether digital should be 1/0 or True/False. What's the most
> widespread convention here? I'm thinking of True/False because that
> makes it obvious that the pin is digital rather than it's simply a very
> low reading on an analog in.
I think digit(al) means digit in base-2. So I prefer 0/1.
Also pins are high/low. 1 for high, 0 for low seems more natural than 
true for high and false for low.

Cheers,
Mark.

>
> Thoughts..? Does this make sense..?
>
> N.
>
>
> On 01/11/15 14:16, Nicholas H.Tollervey wrote:
>> OK... what an interesting discussion. :-)
>>
>> Then I remembered I had a "captive" 11yo in my home! So I asked him
>> which one he preferred (and videoed the discussion). Here's the exchange
>> with my son, over Sunday morning breakfast, in all its glory:
>>
>> https://www.youtube.com/watch?v=9w4I_xEwlcA
>>
>> Put simply he prefers accelerometer.x over .get_x() and .x() because
>> it's less typing.
>>
>> Emboldened by this feedback I've visited some of his buddies this
>> morning (I totally realise this is not at all scientific) to get their
>> opinion.
>>
>> I'm quite surprised by the results - they agree with Sam: ".x" is the
>> unanimous verdict for the best way to express this for all three 11yo
>> I've surveyed. I was expecting ".get_x()" to win because it was obvious
>> what it was doing.
>>
>> But, for example, Max explained that he didn't like all the "weird
>> symbols" and mentioned that, "I don't get 'get', isn't it just 'x'? Why
>> do I need to 'get' it"..? (Max didn't want to be videoed.)
>>
>> Lewis, (whose video is here:
>> https://www.youtube.com/watch?v=uyec2VqYwJs) also likes the simplicity
>> of ".x" and felt that all the others just looked complicated.
>>
>> So, the evidence I've collected so far appears to support Larry and that
>> we should trust the heuristic of "simplicity wins".
>>
>> Once again, I totally realise this is not scientific in any way. But I
>> thought I'd ask those 11yo I had within "range" this morning because
>> they're our target audience.
>>
>> I've been booked to do some gardening this afternoon... but will return
>> this evening.
>>
>> I look forward to reading all your thoughts. :-)
>>
>> N.
>>
>> On 31/10/15 20:08, Carol Willing wrote:
>>> While I am joining this discussion after a couple of months of history,
>>> I am going to step back for a moment and ask a simple question:
>>>
>>> Does this have to be a decision between x, x(), get_x()?
>>>
>>> For the accelerometer (not necessarily all other functionality, but
>>> since the accelerometer is built into the chip and accessible without
>>> soldering anything, it will be used by many), could we support all three?
>>>
>>> If I was an 11 year old with access to Google, I could find resources
>>> appropriate for an 11 year old that use all three of these approaches:
>>> Young Coders workshop, Adafruit/Sparkfun, MicroPython tutorials, Python
>>> for Kids book, and others.
>>>
>>> If I didn't have access to Google, I, as a student, would use `help` or
>>> example programs to model what I would choose. It's critical for the
>>> educational setting for the approach to be consistent within an example
>>> program. While in a perfect world that might imply consistent across all
>>> example programs.
>>>
>>> Yet, we know that there are several approaches to programming that lend
>>> the same result but with differing implementations.
>>>
>>> It seems to me if there is space to support all three for the
>>> accelerometer that would make reasonable sense. We can tailor the help
>>> message to guide to the desired approach; yet, all three will work for
>>> the student whether they are using a recommended approach or something
>>> that they googled.
>>>
>>> Based on my experience teaching a wide spectrum of children, I do think
>>> with gentle instruction all levels will be able to use the accelerometer.
>>>
>>> Warmly,
>>> Carol
>>>
>>>
>>> --
>>> *Carol Willing*
>>> Developer | Willing Consulting
>>> https://willingconsulting.com
>>>
>>>
>>> _______________________________________________
>>> Microbit mailing list
>>> Microbit at python.org
>>> https://mail.python.org/mailman/listinfo/microbit
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Microbit mailing list
>> Microbit at python.org
>> https://mail.python.org/mailman/listinfo/microbit
>>
>
>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>