In response to MrStonedOne
MrStonedOne wrote:
at /tg/ we already type all of our lists.

var/list/turf/simulated/active_turfs

This is ignored by the compiler, but the syntax already works and doesn't break anything.

so getting . to work with lists should be bloody trivial

The syntax works, but the extra type info is not being recorded anywhere. (It's known in the compiler, but when the reference to the var type is compiled it becomes /list.) Typed lists aren't a thing in the DM language; making them so, even with the list being only loosely typed like vars are, would be a big change. So it's not really trivial at all, although at least I wouldn't have to worry about parsing the type path because that part works all right.

Your lists being typed may well be a good idea anyway, as it will simplify your work if something like this ever went in. It doesn't hurt anything and future-proofs you a little bit.
var/list
players[] = new

mob
Login()
global.players[ckey] = src
verb
Example()
src << global.players[ckey]::example_proc()
proc
example_proc()
return "pls lummox"
Urgh. I kinda hate to introduce a new operator here, especially when it does effectively the same thing as the . and : operators. If it came down to that I think I'd rather just use . and tell developers that in these cases, type-safety (the only reason to use the dot operator) is lost.
it should be fairly obvious that type safety goes out the window when stacking calls like this.
Why not just use : since type-safety is already lost anyways?

EDIT: Nevermind, just read the other pages. Proceed!
In response to Lummox JR
Lummox JR wrote:
Urgh. I kinda hate to introduce a new operator here, especially when it does effectively the same thing as the . and : operators. If it came down to that I think I'd rather just use . and tell developers that in these cases, type-safety (the only reason to use the dot operator) is lost.


That would be perfect. o:
Bump..
What about since you have to do
if((variable = proc()) == 1)


You should do
 world << MOB ? (MOB:GetValue():AnothaOne()) : null
#Bump2016
I wholeheartedly do not support this implementation. Type casting is safer and I do not believe implementing this is proper use of dev time.

I'm sorry Koz, I know you want this but ideally you should be typecasting anyways, and there are so many other things that take precedence.
I'll wait another 3 years if I have to >:C
In response to Lavenblade
Lavenblade wrote:
I wholeheartedly do not support this implementation. Type casting is safer and I do not believe implementing this is proper use of dev time.

I'm sorry Koz, I know you want this but ideally you should be typecasting anyways, and there are so many other things that take precedence.

This is a dynamically typed language so this makes no sense.
In response to Somepotato
Somepotato wrote:
Lavenblade wrote:
I wholeheartedly do not support this implementation. Type casting is safer and I do not believe implementing this is proper use of dev time.

I'm sorry Koz, I know you want this but ideally you should be typecasting anyways, and there are so many other things that take precedence.

This is a dynamically typed language so this makes no sense.

Most of what I said makes absolute sense. Typecasting is safer. So many other things that would be a better use of dev time. So many other things take precedence.

EDIT: What about my previous statement doesn't make sense?
You implied that typecasting was a necessity, its only a compiletime safeguard. This would be a massive QoL improvement.
In response to Somepotato
Somepotato wrote:
You implied that typecasting was a necessity, its only a compiletime safeguard. This would be a massive QoL improvement.

Most of the developers here should be typecasting, as it is safer to do so. Sure, this might be handy in the hands of an advanced developer that knows what they're doing, but there are not many that would actually put use to this QoL feature. Thus, dev time could be better spent elsewhere.

You can easily argue that there are still quite a few talented developers around here, and it is true. I would most definitely agree.

How many of those talented developers are actually going to release a game that would take advantage of that feature? Slim to none, unfortunately.

There are other features and improvements to the BYOND Engine that would be more useful to a wider variety of developers.

I do understand the QoL aspect of this, I just feel like it's not super high on the priority list.
Plenty of people would use this feature. There's nothing advanced about it, plenty of languages support method chaining except DM.
In response to Somepotato
Somepotato wrote:
Plenty of people would use this feature. There's nothing advanced about it, plenty of languages support method chaining except DM.

Who would use this feature? I haven't seen anything new being released in a long time.

DM is lacking in many areas in comparison to other languages, not just method chaining.
Surely you know what the code would look like already? Lol.
#Bump2017
I've begun looking more deeply into what it would take to chain proc calls, lists, etc. together. Slowly, I think I'm getting a better handle on the problem.

Here's the dirty secret at the heart of DM that has made this problem difficult: The . and : operators live a dual life. DM uses them along with / as path operators, but it also uses them as var/method access operators. And it turns out to the parser, they're identical.

An expression like a.b.c(d) interpreted by the parser as CALL(a.b.c, d), where CALL is actually an internal version of call(). Likewise x.y.z[1] is INDEX(x.y.z, 1), and the index operator is valid as an LHS expression.

For something like a.b().c to work, what I basically need to do is add a proper . operator, so it's parsed as DOT(a.b(), c). Like with the index operator, this would be potentially usable as an LHS expression.

I'm still in the early stages of figuring all this out, but it looks more and more like it might be an approachable problem.
Page: 1 2 3 4