Literal for creating LWOs

[Zesstra]

Hello everybody,

I thought of introducing a bit of syntactic sugar for leight-weight objects,
specifically for their creation:
I suggest a literal which the compiler translates to a call to new_lwobject(),
e.g.
(<"/lwo/foo"> "Hello", 42, "@WER says: ")
translates to
new_lwobject("/lwo/foo", "Hello", 42, "@WER says: ")

Of course, the literal (<...> ...) is already used for structs. Does anybody
have a nice idea what to use since all brackets in ASCII are already in use?

One Idea, although not terribly "pleasing":
(@"/lwo/foo"@ "Hello", 42, "@WER says: ")
Gnomi does not like this one inspired by objective-c, but maybe it inspires
someone:
[["/lwo/foo"] "Hello", 42, "@WER says: "]

Zesstra@MG
--
MorgenGrauen -
1 Welt, mehr als 200 Programmierer , mehr als 16000 Raeume,
viel mehr als 7000 unterschiedliche Figuren, 90 Quests, 13 Gilden,
ueber 5000 Waffen und Ruestungen, keine Umlaute und ein Haufen Verrueckter.
Existenz: mehr als 25 Jahre
http://mg.mud.de/

[Karl Tiedt]

Of the suggestions the one Gnomi did not like, looks the neatest, the first suggestion only saves ~10 characters... but do any other types of objects have short hands? I suppose if they do, we're not using them really...

Also, more odd syntax means, more broken code highlighters unless someone is finally going to start publishing one for LPC :P 

-Karl Tiedt

--
You received this message because you are subscribed to the Google Groups "LDMud Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ldmud-talk+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/4b9b28f9-3e74-8deb-6906-18e5f5d2b624%40zesstra.de.

[Invisible]

Hello there,

On 07.10.21 00:00, Zesstra wrote:

> One Idea, although not terribly "pleasing":
> (@"/lwo/foo"@ "Hello", 42, "@WER says: ")

no, please, no :-o

> Gnomi does not like this one inspired by objective-c, but maybe it
> inspires someone:
> [["/lwo/foo"] "Hello", 42, "@WER says: "]
>
> Zesstra@MG

[["/lwo/foo"] param] doesn't look too bad. The leading [ suggests that
this is different from a simple data structure like ({, ([, and (<.

But: The use of quotes - while somewhat logical - seems inconsistent
with the struct variant (where no quotes are used). Hence I'd prefer
[[/lwo/foo] param] without the quotes.

That said: I wouldn't worry too much about it. After all, there also is
no literal for creating clones either, and nobody seems to really miss
it. But then again: there could also be a similar syntax for cloning,
e.g. [{/program/file} args] (with the args being passed on to the create
hook, just like - I guess - it will be done for lwobjects).




But those quotes lead me onto a tangent:

Was there ever a plan to allow for dynamically instantiating structs
with the name coming from a string variable? Since structs may inherit
other structs this could be a very useful feature to instantiate
sub-classes of structs as required.

If so, the question would be if that should be allowed at all in the
literal notation of struct and lwobject creation (and thence how to make
it consistent between the two). One way to solve it while staying
consistent with the existing (<StructName>) notation would be borrowing
the struct lookup syntax's () for getting the name from a variable, e.g.:

lwobject ob = [[/a/file/name] foo, bar];
struct st = (<StructName> bla, blub);

vs.

lwobject ob = [[(a_string_variable)] foo, bar];
struct st = (<(a_string_variable)> bla, blub);


The alternative would be to allow quotes if the string is to be
interpreted literally, and otherwise check if the provided name matches
the name of an existing variable. But this of course could break
existing code (so this would have to be an optional feature) and is
presumably harder to implement.


But that said: I would be perfectly happy, if dynamic allocation were
only possible when using new_lwobject() - and in the future maybe a
new_struct() or a variant of to_struct() -, and the literal notation
would only allow for actual string literals. In that case omitting the
quotes to keep it consistent with the existing notation would make more
sense.

cya
  Invis

[Invisible]

On 07.10.21 00:06, Karl Tiedt wrote:
>
> Also, more odd syntax means, more broken code highlighters unless
> someone is finally going to start publishing one for LPC :P

A valid point IMHO, not only from a code highlighter perspective but
complexity in general.

As I already said in my other post: we don't have anything like this for
clones and blueprints, so I guess we don't really need it for lwobjects.

It mainly creates new questions about the consistency of notations,
without any real benefit; "new_lwobject(filename, args)" isn't that much
longer than "[[filename] args]", but easier to read - especially for
newbies.

Maybe restraining creation literals to simple data structures isn't a
bad idea after all. (Or maybe not "simple", but rather "internal to the
object" - which would also cover inline-closures, which I quite like *g*
- as opposed to actually instantiating other objects).

cya,
  Invis