On 05/19/2011 05:43 PM, Richard Dale wrote:
> I think for Ruby we only need to define the name of the property, and we don't
> need the option to define the name of the setter method like you can in C++.
>
> Rather than:
>
> properties 'QString prop READ getProp WRITE changeProp'
>
> I think just this is OK:
>
> properties 'QString prop'
in general, i think so, too. my goal was to fully support the original syntax
and let it "degrade" to the simple case by convention. in that vein one could
make the READ and WRITE fields carry a default and have the methods
autogenerated if necessary.
> For a property called 'prop', two setter methods called 'setProp()' and
> 'prop=' would be generated. If you want to define the three methods in Ruby,
> rather than use the auto generated versions, then that should work too.
you are refering to automatic setters implemented by 'method_missing'? i'm not
sure where they are "generated", as you say. in any case, they would have to
honor the NOTIFY signal, which is the reason i opted to create my own methods.
i'm attaching another patch that implements the 'properties :prop' support
that way.
i don't know what's better, to autocreate each method individually or have
missing_method catch everything.
> Do we need the option to specify a 'NOTIFY' method as well? Or could the name
> always be derived automatically? Would calling the 'prop=' method with the new
> value be OK when a property has changed - do we need three methods to handle
> NOTIFY or will two do?
it works the other way around. the NOTIFY signal should be emitted by the
object when the property changes, cf. the definition of changeProperty (the
setter) in my example. it sets the property and then raises the signal. this
notifies any objects watching the property, e.g. QML objects connected via
property binding.
> You should be able to set the value with any Ruby type and it would get
> converted automatically to a QVariant by the QtRuby runtime.
>
> For example:
>
> foo.prop = 1234
> puts foo.prop
>
> foo.prop = "My String"
> puts foo.prop
>
> foo.prop = Qt::Variant.new(1.23)
> puts foo.prop
so... in my view all variants would end up setting a member @prop to 123, "My
String", or 1.23, respectively, right? the only case i don't support so far is
the last, unwrapping a Qt::Variant if given. that case begs the question of
what happens when i pass a Qt::Variant to a property declared as, say, type
QString. are Variants always unpacked? or does that give a type error?
regards!
--
Sven Moritz Hallberg hallberg at pre-sense.de
Tel. +49 - 40 - 244 2407 - 28
Fax +49 - 40 - 244 2407 - 24
PRESENSE Technologies GmbH Sachsenstr. 5, D-20097 HH
USt-IdNr.: DE263765024
Geschäftsführer/Managing Directors AG Hamburg, HRB 107844
Till Dörges Jürgen Sander Axel Theilmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qtruby-properties-2011-05-20-autoprops.patch
Type: text/x-patch
Size: 1765 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20110520/6f980ff9/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20110520/6f980ff9/attachment.sig>