Robbie,
There are probably people more qualified to answer your question.
However here's my thoughts:
If you look at plain javascript as an example, almost everything seems
to be a function. For example, the Date object has two properties (
.length and .prototype) and almost 50 methods [e.g. getHours(),
getFullYear(), etc.].
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date
My other impression is if the name includes a verb (like "next") I would
probably expect it to be function. For example "getSegment" I would
expect to be a function, but "segment" might not be.
Ultimately people will probably just look up everything to begin with
and get used to whatever you decide.
Good luck!
David
On 10/12/2017 6:11 PM, Robbie Matthews wrote:
This .next() vs .next thing is bothering more than it should.
OK, the principle is that we should use a property if it just returns
a more or less static value, and a function if it does something to
the object.
cursor.next() is legit, because it changes the the internal state of
the cursor (ie, moves it on to the next whatever.
measure.next is actually static, it is a pointer to the next measure,
and calling it does not change the internals.
BUT: cursor.segment() is currently implemented as a function, but it
doesn't change anything, just returns the currently selected segment.
Using Q_PROPERTY gives more control over what it is exposed as, so I
can return wrapped elements without changing the internal name of the
functions.
Using Q_INVOKABLE means I'm stuck with the actual name of the
function, meaning I have to export a different function name if the
existing one does not do what I want.
Then there is the way we've changed the namespace for Q_ENUM, but that
is another issue.
I'm probably overthinking it, but a few guiding principles now may
make life easier for all the the future.
Robbie
On 11/10/2017 3:37 PM, David Bolton wrote:
Robbie,
Speaking to question 5, I appreciate what you are doing. Plugins are
a great way for people to jump into making MuseScore better who have
trouble with C++. Plugins also allow development without having to
rebuild the whole source code which lowers lots of barriers. Plugins
are great for anyone that wants to develop a small feature that is
unique. Sometimes there are features that you want only for a
specific project.
David
On 10/10/2017 8:41 PM, Robbie Matthews wrote:
I've been working steadily on the 3.0 plugins, and have reached a
point where I'd like some feedback.
Discussion to date: https://musescore.org/en/node/255081
PR to date: https://github.com/musescore/MuseScore/pull/3303
Among other things, I posed the question, do we prefer functions or
read only properties?
Specifically, should it be *measure.next* or *measure.next()* ?
jojo-schmidt expressed a preference for functions if they do
something, and properties if they don't.
I have a slight preference for that approach myself, so started
exposing the .next as a Q_INVOKABLE (ie, .next()) rather than a
read only property.
Score represents a problem, in that a) Score is a QObject, so is
exposed directly, as distinct from most other elements, which are
wrappered.
Score::firstMeasure() is already used internally, and I can't just
Q_INVOKE it because it returns an unwrapped Element*
So it is currently exposed as a read only property, which breaks the
pattern I'm trying to estabish.
Question 1: Was the decision to keep Score a QObject critical to
development?
Question 2: Should I in any case create a ScoreW to wrap Score and
register that with QML? (Starting to think so...)
Question 3: Do others have any strong opinions on .next vs .next() ?
Question 4: Is there anything actually documenting what the various
properties do? (for get and set)?
Question 5: Am I wasting my time?
Any input appreciated.
Robbie
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mscore-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
