Please no. The ability to access children this way was a mistake IMO.
8 Likes
Absolutely amazing update! I hope developers are proud with this animation update. 
The issue would be performance. The game would need to check through attributes every time you try to access something. It would also mess up type inferences.
3 Likes
Oh yeah, I also just noticed there isn’t a CFrame type, is there a reason why?
I love this! I feel like the button to add attributes is too big though, and stands out too much.
Maybe something like this would be better?
3 Likes
Already been using this to make descriptions for my objects! Helpful when not everything has a script but I want to add comments!
1 Like
I guess it’s time to change my Value instances into attributes! This is gonna be a long while…
Nice however one thing u would change is maybe adding an image of what the attribute will be so I don’t have to go around and change it.
I don’t see how using a module script to hold values would be inferior and/or replaced by this? Attributes make use of setters and getters (likely due to instance security) which a teensy bit more expensive and is a more complex method of indexing even past the method itself.
Whereas modules, as they literally can be just tables; are far cheaper to manipulate.
module.blah = blah
print(module.blah)
-- v.s
instance:SetAttribute("blah", "blah")
print(instance:GetAttribute("blah"))
and most likely they also cost less memory. I say this because things like the signals for attribute changes, etc; need to have a list or array of the existence of those attributes registered somewhere outside of their initial existences.
I would agree if you said this was more ergonemic and easier to pick up for developers, because that’s a fact. But I don’t know about superior when it’s primarily a measure of complexity? (e.g your use of ‘streamlined’)
6 Likes
Wow! This is a great update! I’ll never have to make a clunky and hard to read model again! 
1 Like
So great. Will be able to finally reduce clutter and more stylistically, and efficiently: set, get, and update values! Cheers!
1 Like
CollectionService exists for the purpose you described.
It’s pretty clear that we have learned our lesson here 
We have briefly discussed the possibility of using . for access when first talking about this feature but very quickly said “no” due to runtime complications with compatibility and performance as well as type system issues. Dot access for children is indeed bad enough as it is.
20 Likes
WOW this arrived quickly! I remember whinging to myself about how much I needed this feature, but thinking how I didn’t want to use a beta feature for production.
Great job to everyone involved and a heartfelt thanks, can’t wait to finally implement this into my codebase. 
With that said; I don’t understand the dot indexing hate. I mean, I probably would not mind using FindFirstChild, but as it stands, this does not work with intellisense; meaning you need to type a lot more if you use FFC instead of dot indexing. I can’t say in good faith that I would have the same patience for development if I had to write :FindFirstChild 200 times per script. Please think about all the poor keyboard switches…
1 Like
Since this is out, does this mean the value instances have no longer uses?
Ergonomics is an important consideration too. GetAttribute is pretty concise, but FindFirstChild gets pretty bad when multiple calls are chained together. It’s actually pretty difficult to debug foo:FindFirstChild("A"):FindFirstChild("B"):FindFirstChild("C") when one of the instances turns out nil; There no way to know which one failed.
I always use FindFirstChild so I can sleep at night knowing a new API isn’t going to break my game. My game’s framework makes it easy for me though, most scripters traverse the DataModel constantly to find things.
10 Likes
Personally I use value instances pretty extensively as databases, since they can store both IDs and values;
I use formats like
<strValue> DatabaseEntry
DatabaseEntry.Name = DB_ID_NUMBER
DatabaseEntry.Value = “Name of the item”
→ <numValue> SomeStat
→ SomeStat.Name = “Damage”
→ SomeStat.Value = 50
and for some other cases. The fact that they are instances is convenient in some cases.
Although I suppose you could replace this with folders now, and just give them attributes accordingly.
1 Like
This is awesome, I am already adapting all of my values into attributes! Question though, is there a way to copy+paste attributes? That would make things so much easier.
Does there happen to be a performance difference between using a bunch of values and instead using attributes?
3 Likes
I certainly don’t think or hope so, values are still useful in a lot of ways.