Here is the latest recording of the bi-weekly community meeting, enjoy!
Hey sorry I missed it again, things have been chaotic and this is at 2:00 AM local time! I will try again in two weeks!
I was pretty confused during the discussion on private vs. public variables(starting around 32 minutes in), I thought “Imba embraces the philosophy that classes should expose everything through methods” so all variables should be private anyways? If you want a variable/field to be public you need to make a
set, or a
prop. There shouldn’t be any marker required for a private variable! I feel like we need to steer the discussion to use a more “Imba” mindset. Maybe I am misunderstanding the problem?
I also strongly believe we should use
prop for readability.
I am really unhappy to see ‘@’ be removed from its role as “class variable”-- though I don’t know how long ago this change was made. What is replacing it? It wasn’t really clear in this video. How do I elegantly produce this behaviour now? This would also prevent any confusion in the example from (1:02:00) with.
owner = owner
I’m not super happy about typed properties, this is the first time I have seen it. I know it is optional. but, once again, Imba is changing to play more nicely with the existing front end framework-- not because it is a more “Imba” way to do it. Is the suggested style going to be to type everything? is this going to be compiler enforced? I appreciate the value of autocomplete, but to switch from untyped to typed (even just stylistically and not compiler enforced) is a huge change, a huge change away from what I thought was the “Imba” way.
YES. owner. = owner is ambiguous. (1:02:00)
Overall this was a really disappointing update. I am In love with the language described on Imba.io, and am aligned with its core philosophy. But that language is no longer supported and with the modern changes I am realizing that Imba v2 is being built on a different set of objectives.
I would be happy to chat about this more in depth any time. I just joined the discord and will try to be more active there, but there is a huge time zone difference so don’t expect me to be online all the time
As Sindre pointed out in the beginning, things are still fairly unstable not just the feature set but the syntax as well. No time limit has been set. This means that anything could really happen in the time between Imba v2 being released and now.
The router lacking is a temporary issue that will be resolved. The main problem here being time and other topics that are considered more important to do first. To be honest, personally I wished we prioritized features/bits that would make it easier to adopt Imba v2 or at least not make it feel like a downgrade at times. Currently, as it stands, you can use Imba v2 but really only for simple use cases. Is using it for bigger apps is going to be very painful. Hopefully, when the data layer stuff has been resolved it can be tackled but let’s wait and see.
We have recordings of previous meetings but I really can’t understand why we added the private variables stuff. I know it’s related to the discussions on implicit self but it’s possible several months back. Maybe I will rewatch the previous ones to relearn the whole rational.
prop is more readable but I am not sure how I feel about it again I have seen issues with it but might just be bugs. Looking at the code you linked to there are differences in Imba v2, like you now have to use
constructor instead of
initialize, add the parenthesis
() to method calls. Do you think these changes are negatives?
Enforcing static types is not something anyone is purposing but having the possibility to define your types clearly is definitely useful when you are working with API’s and the payload matters. I don’t think this will have negative effects on people who only want to use the dynamic parts.
After trying it
x = x inside of a constructor, it’s feeling good, but maybe it’s just because @somebee explained it.
Thanks for your feedback.
Let us know how it goes with the blog.