Re: [Modeling-users] Name for methods valueForKey and takeValueForKey?

[Sebastien B. <sbi...@us...>]

Mario Ruggier <ma...@ru...> writes:
> Hi,
>=20
> i find these names unclear, and even disturbing \-;

  Oh, really, disturbing?

> Should it ever be possible to change them,=20

  It is possible, yes ;)

> and if these names should avoid using 'get' and 'set' not to clash wi=
th
> dedicated getters and setters, then, instead of:
>=20
> valueForKey 		valueForKeyPath
> takeValueForKey   	takeValueForKeyPath
>=20
> I can suggest names such as:
>=20
> retrieveKeyValue 	retrieveKeyPathValue
> assignKeyValue   	assignKeyPathValue
>=20
> or
>=20
> valueFromKey		valueFromKeyPath
> valueForKey		valueForKeyPath
>=20
> or, more consistently, if we reserve the attribute names
> valueByKey and valueByKeyPath:
>=20
> getValueByKey	getValueByKeyPath
> setValueByKey		setValueByKeyPath

Among all these propositions, my preference would go for the last one
(get/setValueByKey) --but I'm not an native english speaker so it's a m=
atter
of taste rather than a matter of linguistics. I also like assign/retrie=
ve,
but this time the inversion of the words (KeyValue vs. ValueForKey) does
disturb me!

> or, even simpler and more elegant (but need extra check per call)
> is to just have the following two methods (reserving attribute name
> keyValue), and determine dynamically whether key specified is
> a simple key or a path (check for '.' should be enough?)
>=20
> getKeyValue=09=09
> setKeyValue

Definitely, yes! This would be more pythonic --I've said that to myself=
 more
than one time. And I can explain why I have not done it yet: the framew=
ork's
core consumes a lot of simple KVC (lots of keys, very few keypaths), and
adding a check here would imply more cpu. However, there's nothing
preventing us from keeping these methods, named (take)valueForKey by no=
w,
for the framework's internal usage and offering the users a more pleasa=
nt
API.

(BTW do you have the same feelings against (take)StoredValueForKey?)


  All in all, this is simply a matter of users' request. Let me know wh=
at
  you all think about it.


        Cheers,

-- S=E9bastien.