I just mean that from a software engineer/developer perspective, context-sensitive arguments used to that extent makes a big mess in terms of readability. Anyone reading code that uses it will want to kill whoever wrote the code and the library.
I'd prefer other designs like named arguments, method overloads or dictionary arguments, but none are available and cheap in LUA. And having 4 optional positional arguments doesn't help the readability either.
I'd prefer other designs like named arguments, method overloads or dictionary arguments, but none are available and cheap in LUA. And having 4 optional positional arguments doesn't help the readability either.
Yeah, sounds like you're caught between a rock and a hard place there.
I like the idea of passing in a table of argument names and values, but I guess that's probably highly inefficient. I don't see it as a bad coding practice in general though for cases like this, given the alternatives.
If efficiency is the issue then you could have a function that takes a table and is just a wrapper for :SetCell(), so that SetCell() could still be used directly when performance is a concern.
They're superimposing a construct not available in the language, nor does it make sense.
It's definitely not intuitive.
When working within a language I believe we should stick to whats reasonably possible given the language's constructs.
:Set('x', 500, 'y', 200)
for example is a HORRIBLE syntax.
Yes if you pass every argument like this. However I was thinking to use only for optional argument and to keep mandatory argument at fixed places. It is close to what is possible in Python. By example:
I like the idea of passing in a table of argument names and values, but I guess that's probably highly inefficient. I don't see it as a bad coding practice in general though for cases like this, given the alternatives.
If efficiency is the issue then you could have a function that takes a table and is just a wrapper for :SetCell(), so that SetCell() could still be used directly when performance is a concern.
The "issue" is the table creation itself, or more precisely the table disposal. Long story short, to my understanding creating too many table too quickly leads to running the garbage collector more often and this is a costly operation.
Yes if you pass every argument like this. However I was thinking to use only for optional argument and to keep mandatory argument at fixed places. It is close to what is possible in Python. By example:
tip:SetCell(1, 2, 'value', 'font', MyFont)
The "issue" is the table creation itself, or more precisely the table disposal. Long story short, to my understanding creating too many table too quickly leads to running the garbage collector more often and this is a costly operation.
to me mixing them is even worse, as there is no clear cut way to tell whats going on by looking at it. That API will confuse people I'd much rather have some nasty detection code if we have to
I know the garbage cycling issue was a definite issue in older WoWs but I'm not so sure about the newer one. In general though passing a table as an argument is discouraged.
I know the garbage cycling issue was a definite issue in older WoWs but I'm not so sure about the newer one. In general though passing a table as an argument is discouraged.
People are still seeing the "block too big" crashes in WotLK beta, so I'd assume the issue persists.
And yeah, mixing is ugly and would be best avoided if possible.
Is is possible to create some kind of standardized custom data structure/object that can be populated and passed in? This wouldn't have garbage collection issues because it could exist as a singleton in the addon that is passing it. Yes, it precludes the ability to do simple one-liner calls, but it avoids a lot of potential clunky back-end work.
Edit: It would also allow you to implement additional optional parameters without breaking backwards compatibility with addons that use it.
No dictionary or named arguments imo, the damn thing is grumpy as it is. Either find a viable way to pass a predefined unique object with the required attributes (that WILL be easier to read) or leave it as it is (or eliminate the cellProvider !! :pp).
As far as a license I'm a fan of the one I used for Ace3. Allows unfettered usage by authors, but stops people like wowmatrix from legally being able to distribute it.
As far as a license I'm a fan of the one I used for Ace3. Allows unfettered usage by authors, but stops people like wowmatrix from legally being able to distribute it.
Though I'm still not sure of the real impact of the additional clause, this license seems fine to me.
Just had some random thoughts about some light additionnal API :
These two methods would allow to iterate the columns and lines frames:
function tip:IterateColumns() return pairs(self.columns) end
function tip:IterateLines() return pairs(self.lines) end
Moreover we might add the possibility to add an 'OnRelease' callback to these frames.
This way one could "mess" with lines and columns (who said "clicky lines and
putting a scrollbar in a whole column" ? I've heard you !) and still clean them.
Or maybe this is way to advanced ? or should we use proper callbacks (CBH) ?
I started to document the API (keep in mind this is the API reference, not the tutorial/getting started guide). I have to say that the wiki header styles are terrible. >:(
Looks nice so far Adi. I believe a more comprehensive description for cell providers, preferably with an example, is in order, so it makes better sense.
Looks nice so far Adi. I believe a more comprehensive description for cell providers, preferably with an example, is in order, so it makes better sense.
I'll add more pages like "cell provider sample" and such later.
Moreover we might add the possibility to add an 'OnRelease' callback to these frames.
This way one could "mess" with lines and columns (who said "clicky lines and
putting a scrollbar in a whole column" ? I've heard you !) and still clean them.
Or maybe this is way to advanced ? or should we use proper callbacks (CBH) ?
I'm listening...other than user-provided/cleanup 'clickies', what else could this provide? I'm still half asleep, but this sounds like a way to make the library powerful while keeping it lightweight.
I'm listening...other than user-provided/cleanup 'clickies', what else could this provide? I'm still half asleep, but this sounds like a way to make the library powerful while keeping it lightweight.
This idea was to generate LineAcquired, LineReleased (and ColumnXXX) events. One could use these callback to customize those frames (e.g. make them clicky or whatever). However, this might just be overkill.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'd prefer other designs like named arguments, method overloads or dictionary arguments, but none are available and cheap in LUA. And having 4 optional positional arguments doesn't help the readability either.
That's horrible reasoning :p
Yeah, sounds like you're caught between a rock and a hard place there.
Not saying it is the best reasoning, but ya it's definitely a rock/hardplace situation.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIt's definitely not intuitive.
When working within a language I believe we should stick to whats reasonably possible given the language's constructs.
:Set('x', 500, 'y', 200)
for example is a HORRIBLE syntax.
I like the idea of passing in a table of argument names and values, but I guess that's probably highly inefficient. I don't see it as a bad coding practice in general though for cases like this, given the alternatives.
If efficiency is the issue then you could have a function that takes a table and is just a wrapper for :SetCell(), so that SetCell() could still be used directly when performance is a concern.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYes if you pass every argument like this. However I was thinking to use only for optional argument and to keep mandatory argument at fixed places. It is close to what is possible in Python. By example:
The "issue" is the table creation itself, or more precisely the table disposal. Long story short, to my understanding creating too many table too quickly leads to running the garbage collector more often and this is a costly operation.
to me mixing them is even worse, as there is no clear cut way to tell whats going on by looking at it. That API will confuse people I'd much rather have some nasty detection code if we have to
I know the garbage cycling issue was a definite issue in older WoWs but I'm not so sure about the newer one. In general though passing a table as an argument is discouraged.
People are still seeing the "block too big" crashes in WotLK beta, so I'd assume the issue persists.
And yeah, mixing is ugly and would be best avoided if possible.
Is is possible to create some kind of standardized custom data structure/object that can be populated and passed in? This wouldn't have garbage collection issues because it could exist as a singleton in the addon that is passing it. Yes, it precludes the ability to do simple one-liner calls, but it avoids a lot of potential clunky back-end work.
Edit: It would also allow you to implement additional optional parameters without breaking backwards compatibility with addons that use it.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThough I'm still not sure of the real impact of the additional clause, this license seems fine to me.
Just had some random thoughts about some light additionnal API :
These two methods would allow to iterate the columns and lines frames:
function tip:IterateColumns() return pairs(self.columns) end
function tip:IterateLines() return pairs(self.lines) end
Moreover we might add the possibility to add an 'OnRelease' callback to these frames.
This way one could "mess" with lines and columns (who said "clicky lines and
putting a scrollbar in a whole column" ? I've heard you !) and still clean them.
Or maybe this is way to advanced ? or should we use proper callbacks (CBH) ?
You were just hearing voices. Ignore them.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI'll add more pages like "cell provider sample" and such later.
-
View User Profile
-
View Posts
-
Send Message
AdminI have no problem with it either.
That could prove useful. Test cases? :)
I'm listening...other than user-provided/cleanup 'clickies', what else could this provide? I'm still half asleep, but this sounds like a way to make the library powerful while keeping it lightweight.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis idea was to generate LineAcquired, LineReleased (and ColumnXXX) events. One could use these callback to customize those frames (e.g. make them clicky or whatever). However, this might just be overkill.