I agree on this one, I often use lowercase names for attributes so they will never conflict with existing Roblox default properties/attributes.
1 Like
Gets down on knees to pray to overlord builderman
No, really, this is SICK! Can’t wait to use this!
Scripting go 
3 Likes
I really hope this feature gets released soon, it’ll make for much better code structures and stuff like MVC framework etc. I also don’t want to go back to ValueObjects 
- Amazing work on this feature!
5 Likes
Bump, the sooner this is released the better. Creating value objects is not at all an optimal system, comparatively speaking.
1 Like
Yes, this is what it is used for.
1 Like
Yea well:
Roblox could release another name conflict any day now
Perhaps an output warning could be displayed if you are trying to create an attribute or rename an existing attribute, to a property of that instance. For example, if you were to make an attribute called ‘Name’ for a part, a warning would show up; “Attribute ‘Name’ conflicting with property ‘Name’.”. Perhaps this warning could even be shown in the code editor itself, so you notice the mistake before it is too late.
So… I know the limit is really large, but what’s the actual limit of the amount of attributes that can be created/stored (in studio and in real time)?
I tried to test this out but almost ended up crashing studio.
When can I expect attributes to throw errors at me for creating too many, etc?
Does it throw an error at all or does it just stop working without warning?
I couldn’t test this as this sort of slowed down Studio a lot when I had thousands of attributes.
Edit: Also is there a way to remove attributes with code? I only see Get-/SetAttribute() but no DeleteAttribute() or anything.
Edit2: I also found a bug that when stopping play/run mode after creating about 40,000 attributes or so some of them stay in edit mode.
Edit3: Even worse, it appears that creating too many attributes and exiting play test mode makes them spread to other objects and services like a virus, talking about all objects and descendants in studio now have them.
Could you please create a separate topic with more information or message me directly? I’m unable to reproduce this myself.
Attributes are held in memory, therefore you are limited by the memory of the device you are using. This is the same for tags, and creating instances.
In the original post I included some code samples which included how to remove an attribute, I recommend checking those out!
5 Likes
Can’t you already tween attributes? TweenService can support any value type that’s listen on that page.
1 Like
Yes, but TweenService can only tween properties right now, not attributes.
3 Likes
It would be awesome if we could access all members of an object with :GetAttribute()
i.e ImageLabel:GetAttribute(“ScaleType”)
What’s your specific use-case? Assuming you know it’s a property, this can already be done with:
ImageLabel["ScaleType"]
1 Like
My specific use-case comes from when I am receiving two Instances where one has a property and the other has an attribute.
local UserId
local success,error = pcall(function()
UserId = player.UserId
end)
if not success then
UserId = player:GetAttribute("UserId")
end
It would be nice to access all members of an object with :Get() and :Set() functions, since if we’re trying to mock existing Instances that can’t be created (not able to create user defined interfaces yet) we could do so with a universal pipeline that also has the benefit of being more declarative and allowing polymorphism to exist.
AHH I can see that being a real pain in the rear going forwards smh. Attributes should work with tweenservice 
I’ve been searching around and I’m surprised that no one has suggested this one yet.
How about read-only attributes that can be written to in Studio, but not written to in-game? I have a playerdata system that uses attributes and I want the ability to set some attributes to read-only so exploits will have a harder time setting said values.
1 Like
That’s essentially pointless. Normal exploiters won’t bother attempting to create exploits because they rely on the professionals for the scripts, who will be able to easily bypass it. They will find a way regardless of if it’s read only or writable.
One possible use case would possibly be for a better code debugging process? If for whatever reason a script is attempting to mutate an attribute that isn’t supposed to be, then you could easily track where it happened.
Someone mentioned something like this earlier, but let me reiterate and suggest that a custom object be added that’s essentially like a folder with no behavior and almost no properties on it’s own, but supports the use of the dot operator to index attributes. Please don’t make us use player.Data:GetAttribute(“coins”), or people including myself will just end up using custom wrappers anyway.
Apologies if this has been asked before is it possible for me to be able to look through the entire workspace for specific attributes?
1 Like
Are you looking for the name of the attribute, or the instance that has attributes? We’re looking into how we might make it easier to do searches/filtering.
1 Like