Add static variables

[rozaxe]

⭐️ Proposed change

I propose a way to define instance variables which can be called on the type rather on an instance of the type.

🤔 Rationale

This would allows to store values on a type, and use them from type methods.

This would also allows the development of the singleton pattern.

🕺Example

Here an example of an implementation of the singleton pattern :

🐇💾🍇

	🐇🖍🆕 instance 🍬💾

	🔐🆕🍇🍉

	🐇❗️🐾 ➡️ 💾 🍇
		↪️🤷‍♂️ 🙌 instance 🍇
			🆕💾🆕❗️ ➡️ 🐇🖍instance
		🍉

		↩️ 🍺instance
	🍉
🍉

This defines a static variable 🐇🖍🆕 instance 🍬💾 accessibles from the type itself with 🐇instance.

We can then call the singleton with 🐾🐇💾❗️ and access the unique instance of the type 💾

[thbwd]

Perfect except that I don't think ➡️🐇🖍instance is good. ➡️🖍instance like with instance methods would be better. After all, type methods really are in the context of the type. (🐕 contains the type.)

[thbwd]

You wanna try to implement this? 🙂

[rozaxe]

At least I will try ! 😁

[rozaxe]

I am digging into implementing this, and I found a problem. How a static variable initial value would be set ?

🐇 🐟 🍇
  🐇🖍🆕 count 🔡

  🐇 ❗️ 🙇‍♀️ 🍇
    count ➕ 1 ➡️ 🖍 count
  🍉

  🐇 ❗️ 💁‍♂️ 🍇
    😀 count ❗️
  🍉
🍉

For example, what would be count initial value ?

Do you think we could add "on step declaration and assignment variable" in type as well ?

Something like that :

🐇 👩‍💼 🍇
  5300 ➡️ 🖍🆕 money
  🆕 🍇🍉
🍉

After calling 🆕👩‍💼🆕 the value of money would be set to 5300 ?

Thus, we could write something like that for static variables :

🐇 🐟 🍇
  0 ➡️ 🐇🖍🆕 count
🍉

[thbwd]

Declaring and Assigning in one step in types would be great.

These expressions would have to be evaluated in a context where 🐕 (and thus access to instance variables) is disallowed, I guess.

[thbwd]

@rozaxe Can you please give me a heads-up before you implement anything concerning the declaration and assignment in type bodies? I want to some refactoring here first, if possible.

[rozaxe]

No problem, go again ! (I need some time to understand how the compile works in whole, so do not hesitate to implements features)

[thbwd]

So we have a syntax issue here. Consider this code:

🐇 👩‍💼 🍇
  🆕🦍🆕❗️ ➡️ 🖍🆕 pet
🍉

While this is a variable assignment, it is hard for the compiler to tell it apart from an initializer definition:

🐇 👩‍💼 🍇
  🆕🦍 🍇
  🍉
🍉

Emojicode uses a strict LL(1) grammar, which makes this impossible. I think the best solution is:

🐇 👩‍💼 🍇
 🖍🆕 pet ⬅️ 🆕🦍🆕 ❗️
🍉

[rozaxe]

So for recap, for instance variable :

🖍🆕 pet ⬅️ 🆕🦍🆕 ❗️

And for "in method variable" :

🆕🦍🆕 ❗️➡️ 🖍🆕 pet

[thbwd]

Yes, although I think it might even be

🖍🆕 pet 🦍 ⬅️ 🆕🦍🆕 ❗️

because type inference could be difficult here. Furthermore, a well-reasoned argument against something like this was made in #83 .

[thbwd]

✅ This is implemented on 0.7.

https://0-7.emojicode.org/docs/reference/classes-valuetypes.html#instance-variables

[rozaxe]

Sorry, I do not feel I will be able to implement this (too many knowledge).
I will keep my motivation for implementing some useful package !

[thbwd]

@rozaxe That’s alright. I myself have refrained from implementing exactly this in the past because it is rather complicated. I’ll remove it from the 1.0 milestone then, though.