Language: properties of opened things

[DarScott]

Objects have properties.

It might be nice for things that are open to have properties, that is, sockets, processes, drivers (serial devices) and files.

This might provide a schema for talking about improvements to using those.

Also, it might provide a basis for doing things in a consistent way. The property "bytes waiting" might apply to both drivers and processes. (There might be a better name.)

Some would have unique properties. Drivers might have "RTS", a serial handshake line. Sockets might have "reuse socket" or the standard socket option name.

The syntax would be exactly the same as for objects:

Code: Select all

set the RTS of driver southRS485 to true

This might apply to my immediate discussion (in Engine Contributions) of multicasting or socket options. It might apply to my future discussion of serial I/O.

[DarScott]

The notion of properties of opened things is a sort of namespace feature. It avoided the clutter of new commands and functions in LiveCode.

[LCMark]

@DarScott: I've always thought of things like 'file', 'socket', 'process' etc. as 'pseudo-objects'. The syntax is hard-coded for them but they still 'feel' like things that should act like chunk expressions. There are other ones lurking around in the syntax too (albeit slightly more hidden) - things like 'the screenRects' and 'the screenPixelScales' as I think these should really be:

Code: Select all

  the rect of the main screen
  the rect of screen <n>
  the pixelScale of screen <n>

Adding the syntax for this when Open Language arrives will be incredibly easy - you just add an explicit syntax rule which includes the pseudo-object reference:

Code: Select all

  'the' 'bytes' 'waiting' 'of' 'socket' <name: expr>
    => GetBytesWaitingOfSocket(name as string) returns integer

I'm sure there are other 'named' abstractions in LiveCode which could get the same treatment too.

[DarScott]

@runrevmark: So, would you recommend adding a suite of complementary "property" functions and setting commands and then, when Open Language comes, create the appropriate package of syntax rules to complement them?

[DarScott]

I wonder if it is possible to bypass adding commands and function names to LiveCode and go straight to properties syntax.

I wonder what expectations come up when the term "properties" is used.

[LCMark]

@DarScott: I'll take a look at the current syntax parsing code for Chunks and such and see how difficult it would be to add 'pseudo-object' property syntax now - its a little tricky at the moment as we have both the current MCChunk implementation (on master/develop) and the refactored version (on refactor-syntax_unicode). @runrevali has had a fair few headaches refashioning MCChunk to work how it needs to in refactor-syntax_unicode in order that Open Language can be applied to it, so for the time being its a little bit of a tricky area.

[DarScott]

Would functions used by Open Language be in a separate namespace or would they be part of myriad of LiveCode functions?

[DarScott]

Perhaps these functions can be added to LiveCode and people can contribute to the switch inside and even add to platform specific parts.

Code: Select all

command setSocketProperty socket, propertyName, propertyValue
function socketProperty socket, propertyName

command setDriverProperty driver, propertyName, propertyValue
function driverProperty driver, propertyName

command setProcessProperty process, propertyName, propertyValue
function processProperty process, propertyName

For sockets, socket properties include socket options, identified by distinctive names. Others might have low level attributes, too.

Where possible, these can share high level property names. An example might be "bytesWaiting" as illustrated by the above example.

Then at the appropriate time, a properties syntax can apply. Perhaps this is through Open Language.

What might people try to do with these properties that they can do with object properties that is not accounted for here?

Are these command and function names likely to clash with what people are already doing?

[DarScott]

I mention socket options being handled as socket properties.

Some are read-only. That is found in our experience with object properties.

Some socket options are really imperatives. An example is IP_DROP_MEMBERSHIP. That might be write-only.

Perhaps a higher level property is more appropriate than the low level socket options for managing lists. Consistency would have to be addressed.

[DarScott]

We can find times where properties should be or must be set at the LiveCode 'open' or 'accept' for sockets, drivers and processes. Setting the properties afterward might not have the desired outcome.

There might be several ways to do this.

We can be inspired by object templates. Everywhere a socket, driver or process can be used in the above mentioned commands and functions, the template can be used. Like this:

Code: Select all

setSocketProperty templateSocket, "SO_REUSEPORT", true

We would want to reset as we can object templates:

Code: Select all

resetIOTemplate templateSocket

If these include socket options, they should be handled after the higher-level properties in an 'open socket' or 'open datagram socket'. Or maybe some properties are not allowed for IO templates.

There should be some way that these can work well with some of the other ways we have to handle this now:

• allowDatagramBroadcasts
  defaultNetworkInterface
  hideConsoleWindows
  serialControlString

What have I missed that belongs in this list?

These might be views into I/O templates. For example, setting the serialControlString sets the appropriate properties in the templateDriver (the template for serial I/O) and getting it builds it based on the templateDriver. If new allowed values are added in the properties for properties also reflected in serialControlString, the serialControlString should be enhanced to be consistent. If possible the serialControlString should have some level of compatibility with mode in Windows, but I don't think that is a strong druther as long as there is an easy way to descriptor the difference.

There are potential problems if the current methods trigger some song-and-dance in open to get around bugs and quirks on some platforms and OS versions. The corresponding properties might need the matching level of abstraction and good service.

(We use serial in serialControlString and driver in driverNames. Unless we see drivers as becoming more general than serial, then maybe all places they can be sub-name synonyms. Or will that explode?)

I don't think the current methods for setting up I/O open should be depreciated, they might have good pedological uses. Also, serialControlString might be nice for people coming from some other Windows programming environment.

Have I wandered off way beyond where the lifeguard can see me?

[livecodeali]

Hi Dar,

Adding this feature proved relatively easy in the refactored branch of the engine. I have taken the liberty of implementing "screen", "socket", "file" and "process" as pseudo objects- this is pushed to github in a branch of my repo: runrevali/livecode/tree/feature_pseudo-object_props

So far I have just implemented the following four pieces of syntax:
the openmode of file <open file name>
the openmode of process <open process name>
the name of socket <open socket name>
the rect of screen <n>

The 'name of socket' example is obviously pretty useless in every way other than being an example!
If you'd like to start developing some property getters/setters for sockets, then take a look at that branch. Hopefully it's quite straightforward to add properties now that the structure is in place. I'm planning on writing a blog post about this next week, where I will go into a bit more detail about how it works and how to extend it.

Ali

[DarScott]

cool! I hope to be all github soon!

[mwieder]

Adding this feature proved relatively easy in the refactored branch of the engine.

!!! I really like the idea of pseudo-objects. Feels like we're on our way to actual OOP.

[SirWobbyTheFirst]

Adding this feature proved relatively easy in the refactored branch of the engine. I have taken the liberty of implementing "screen", "socket", "file" and "process" as pseudo objects- this is pushed to github in a branch of my repo: runrevali/livecode/tree/feature_pseudo-object_props

...
the rect of screen <n>

Would that mean one would be able to grab information about the monitors connected to the computer? I would find this useful to avoid having to ask the user to specify resolution and multi-monitor configuration information for Nix's desktop and automatically detect the information itself. For example would I be able to do this:

Code: Select all

Put The Number Of Displays Into tMonitorCount
Put The ScreenRect Of Screen 1 Into tPrimaryScreenResolution // Which could be 1920x1080 for example.
Put The ScreenRect Of Screen 2 Into tSecondaryScreenResolution // Which could be a 1280x1024 display.

And then be able to have the code in Nix's window manager setup two desktop stacks at different sizes to fit each monitor? If so that would be the bees knees and would allow me to drop the current hacky method I have on Windows for using PowerShell and WMI. Blerck, that stuff is hideous and asking the user for that kind of info is subject to millions of data checks to make sure they don't unwittingly hack the NSA using a simple text editor.

[jacque]

Would that mean one would be able to grab information about the monitors connected to the computer?

You can do this already. See "screenrects" in the dictionary. The number of lines returned is the number of monitors. Each line is the screenrect of one monitor.