Cleaning up condition syntax

  Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
Hitcher Offline
Skilled Skinner
Posts: 10,859
Joined: Aug 2007
Reputation: 101
Location: Eastleigh, UK
Post: #31
Jezz_X Wrote:the only real changes to that I would like is to allow other infolabels to be a suffix or prefix for another
eg: $INFO[MusicPlayer.Artist,,- $INFO[MusicPlayer.Album]] will not work currently

+1
find quote
jmarshall Offline
Team-XBMC Developer
Posts: 26,221
Joined: Oct 2003
Reputation: 178
Post: #32
Ok, for a start, I'm not planning on going all out just yet - let's keep it simple Smile

The first step is a common format for info retrieval as specified by Black earlier.

i.e. Control.IsVisible(50) would simply be Control(50).IsVisible.

Simply put: Any argument/parameter is stuck on the bit of the infolabel it actually affects - the 50 refers to Control 50, not the 50th IsVisible (whatever that means).

I'm also only considering boolean operations at the moment, as they're really the simplest.

However, some boolean operations are functions rather than properties:

isempty(foo)
stringcompare(foo,bar[,left|right])
integergreaterthan(foo,2)
system.date(value1[,value2])
system.time(value1[,value2])

It's not quite as obvious how these should be best formatted so that they're both obvious to skinners and easy to parse in the code. The last 2 for instance are completely non-obvious to me as there's no indication that value1 and value2 are there for comparison.

One option is to not distinguish between properties and functions in terms of syntax:

foo.isempty
foo.left(3).equals(bar)
system.time.inrange(value1,value2)

This would involve quite a shift in the way the code works internally (it would essentially move to an object orientated approach where each object has parameters, properties (which may be objects) and functions), but I do quite like the idea behind it.

Cheers,
Jonathan

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


[Image: badge.gif]
find quote
ronie Offline
Team-Kodi Member
Posts: 9,308
Joined: Jan 2009
Reputation: 161
Post: #33
makes sense and sounds reasonable to me.

the only thing to worry about is if it's possible to get everything in the proposed
Category[(cat_params)].Info[(info_params)][.SubInfo[(subinfo_params)]] format.

this one seems tricky, at least to me:
foo.left(3).equals(bar)

in case of a window property, you'll get something like:
window.property(foo).left(3).equals(bar)

maybe this would make more sense:
window.property(foo,left(3)).equals(bar)



another thing i wonder about is a boolean like system.platform.linux...
will this become
a) system.platform(linux)
b) system.platform.equals(linux)
c) system.hasplatform(linux)
or
d) none of the above

Always read the Kodi online-manual, FAQ and search the forum before posting.
Do not PM or e-mail Team-Kodi members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
find quote
jmarshall Offline
Team-XBMC Developer
Posts: 26,221
Joined: Oct 2003
Reputation: 178
Post: #34
Quote:this one seems tricky, at least to me:
foo.left(3).equals(bar)

It means "take foo, then take only the left 3 characters, then see if it's equal to bar". Basically anything following a period is either a property of or a function that operates on whatever is before the period.

Quote:in case of a window property, you'll get something like:
window.property(foo).left(3).equals(bar)

maybe this would make more sense:
window.property(foo,left(3)).equals(bar)

The first makes most sense to me, as the left(3) operates on what preceeds it (window.property(foo)) and similarly, property operates on "window", and "equals" operates on the result of "window.property(foo).left(3)".

If we want to distinguish between functions and properties then we could use something like:

equals(left(window.property(foo),3),bar)
or
stringcompare(window.property(foo),bar,0,3)

i.e. a function is of the form:

function_name(parameters)

Quote:another thing i wonder about is a boolean like system.platform.linux...
will this become
a) system.platform(linux)
b) system.platform.equals(linux)
c) system.hasplatform(linux)
or
d) none of the above

I think a, b, or c would work, though b seems to be most useful should we go that way, as that means that system.platform is a string that returns "linux".

Cheers,
Jonathan

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


[Image: badge.gif]
find quote
topfs2 Offline
Team-Kodi Developer
Posts: 4,084
Joined: Dec 2007
Reputation: 12
Post: #35
Regarding window.property(foo) wouldn't it make sense to just do
Window.foo instead? and Window(another_window_id).foo if needed? I guess I'm thinking properties to be somewhat of a member variable of the "object" Window in this case.

So it would be Window.foo.Left(3).equals(bar)

My thinking is that then it would fit quite well with other stuff like System.Platform and perhaps Power.CanPowerdown as you kindof have Namespace.Property or Namespace.Function or Namespace.Property.Function etc. (You could easily switch namespace with category whichever naming works)

So I guess Control.foo would be short for Window.Control.foo (as Window resolves to current window), otherwise it would be Window(settings).Control(3).IsVisible

If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

[Image: badge.gif]

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
find quote
jmarshall Offline
Team-XBMC Developer
Posts: 26,221
Joined: Oct 2003
Reputation: 178
Post: #36
We could potentially do that, yes - the advantage would be simplifying the syntax. The disadvantage I guess is that it removes some of the definitiveness of the "built in" properties. Not sure if this is a big deal or not though!

It would be nice if this had a natural translation into json - any ideas there?

I'm not sure if we have differentiation between "hasproperty" and "property" at the moment, but that distinction will have to be made somewhere if we're going to have object types (as window.foo would generally return a string by default for properties) - I should think that casting a string object to a boolean object should be natural enough (assumes isempty is the operator).

Cheers,
Jonathan

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


[Image: badge.gif]
(This post was last modified: 2011-07-14 00:29 by jmarshall.)
find quote
Post Reply