I may not be a developer or one of the top scripters here, but I'm a contributing member of this community and I think I have the right not to be pummeled with degrading, unhelpful, and sardonic comments such as this one. I think the developers, who are supposed to be the leaders of the community, are being unfair to attack someone who made the unfortunate mistake of breaking an unwritten rule. A rule that I had no way of knowing -- in my own job, the term is perfectly acceptable among programmers. Thankfully the non-developers have been understanding that it was a mistake to use that word, which I have readily admitted several times.
ZLib -- Zarqon's useful function library
- Thread starter zarqon
- Start date
I may not be a developer or one of the top scripters here, but I'm a contributing member of this community and I think I have the right not to be pummeled with degrading, unhelpful, and sardonic comments such as this one. I think the developers, who are supposed to be the leaders of the community, are being unfair to attack someone who made the unfortunate mistake of breaking an unwritten rule. A rule that I had no way of knowing -- in my own job, the term is perfectly acceptable among programmers. Thankfully the non-developers have been understanding that it was a mistake to use that word, which I have readily admitted several times.
Theraze
Active member
But then you make it worse by trying to 'defend' yourself. And you keep dragging it out more and more, which makes those of us who haven't blocked you consider it. 
Regardless of how YOU feel about the words you use, the developers who actually make the magic happen don't like it. When you realize that you're making them upset with you, it's a good idea to stop whatever it is that makes them upset. Does that word make you upset? Nope. Does it make them upset? Yep. Does that mean that you should try to convince them that it's wrong for them to not like that word? Nope, not unless you want them to stop listening to you.
Additionally, when you read through the Bug Report Procedures stickies in the Bug Report forum, which of course any good forum user would do before posting any bug report anywhere, whether mafia itself or in a script, it specifically states:
You call it an unwritten rule. I call it a written one. Who is right? Nobody. This is the internet. People can argue for years and nothing positive happens except for threads being derailed.
How about we move talking in this thread in the future back to ZLib itself, rather than internet jihads. It will lead to being less-blocked in the future.
Regardless of how YOU feel about the words you use, the developers who actually make the magic happen don't like it. When you realize that you're making them upset with you, it's a good idea to stop whatever it is that makes them upset. Does that word make you upset? Nope. Does it make them upset? Yep. Does that mean that you should try to convince them that it's wrong for them to not like that word? Nope, not unless you want them to stop listening to you.
Additionally, when you read through the Bug Report Procedures stickies in the Bug Report forum, which of course any good forum user would do before posting any bug report anywhere, whether mafia itself or in a script, it specifically states:
Since that post has been up for almost 3 years, of COURSE you've read it and know to avoid using those words. I mean, you're
You call it an unwritten rule. I call it a written one. Who is right? Nobody. This is the internet. People can argue for years and nothing positive happens except for threads being derailed.
How about we move talking in this thread in the future back to ZLib itself, rather than internet jihads. It will lead to being less-blocked in the future.
But then you make it worse by trying to 'defend' yourself. And you keep dragging it out more and more, which makes those of us who haven't blocked you consider it.
Regardless of how YOU feel about the words you use, the developers who actually make the magic happen don't like it. When you realize that you're making them upset with you, it's a good idea to stop whatever it is that makes them upset. Does that word make you upset? Nope. Does it make them upset? Yep. Does that mean that you should try to convince them that it's wrong for them to not like that word? Nope, not unless you want them to stop listening to you.
Additionally, when you read through the Bug Report Procedures stickies in the Bug Report forum, which of course any good forum user would do before posting any bug report anywhere, whether mafia itself or in a script, it specifically states:Since that post has been up for almost 3 years, of COURSE you've read it and know to avoid using those words. I mean, you're
You call it an unwritten rule. I call it a written one. Who is right? Nobody. This is the internet. People can argue for years and nothing positive happens except for threads being derailed.
How about we move talking in this thread in the future back to ZLib itself, rather than internet jihads. It will lead to being less-blocked in the future.
You are right, I guess I am just frustrated.
BUT! The new WOSSMAN is super useful. Thanks Zarqon!
Actually, I wasn't upset by you and was trying to be helpful. In the years I've spent on the internet and the real world (I'm not young), I've seen a huge difference in the success of complaints or issues raised in getting fixed, based on the way the request is phrased. I was only saying that it isn't only here that being objective, clear and non emotive that helps.
Of course, it is difficult to convey that in text sometimes.
Yeah don't I know it. Anyway I am sorry, I guess I sensed hostility where there was none.
Last edited:
Theraze
Active member
It's sort of an official unofficial variable. It's subject to change at any point where Zarqon decides to change his "save this!" name, but if you're manually trying to create your own overrides, setting zlib[whatever] and then running updatevars() is the easiest way to do it.
zarqon
Well-known member
If ASH was the sort of language where we declared public and private functions, it would be a private function. The idea being that script settings are user-configurable values and shouldn't need to be adjusted by the scripts themselves (an obvious exception is a script settings GUI that allows the user to adjust his settings). So its omission from the wiki is deliberate; use it at your own risk. That said, I'm not a jerk and unless I have a good reason to change the name I won't.
TPTB are breaking enough scripts as it is without me helping them.
roippi
Developer
tangent
As I program in more and more languages, I'm increasingly of the opinion that public/protected/private/whatever members are non-features of a language. Nowadays I agree with a philosophy in the python community: "we're all consenting adults here." If someone really wants access to some method that I intended to be private, who am I to stop them? Instead the convention in python is to prepend any attribute names with an underscore that you want to let people know are "implementation details and subject to change." You can feel free to use my _experimentalFuncImpl() but when it breaks in the future it's your fault not mine
/tangent
As I program in more and more languages, I'm increasingly of the opinion that public/protected/private/whatever members are non-features of a language. Nowadays I agree with a philosophy in the python community: "we're all consenting adults here." If someone really wants access to some method that I intended to be private, who am I to stop them? Instead the convention in python is to prepend any attribute names with an underscore that you want to let people know are "implementation details and subject to change." You can feel free to use my _experimentalFuncImpl() but when it breaks in the future it's your fault not mine
/tangent
Fluxxdog
Active member
orthogonal tangent
From my understanding, it was more a tool to aid the original coder in deciding what (not who) could use a function/variable. While it may not be as useful when your work is intended to be imported by others, such as a math library, for an enclosed project, it can help keep things from using the wrong functions/variables. In truth, I've found it helpful for monitoring my own flow. I guess I've really yet to hear others describe how they use them, especially Veracity and holatuwol. I'm sure they would have a lot of insight as to how those permission words affect their work, if they care to comment. Please?
/ot
From my understanding, it was more a tool to aid the original coder in deciding what (not who) could use a function/variable. While it may not be as useful when your work is intended to be imported by others, such as a math library, for an enclosed project, it can help keep things from using the wrong functions/variables. In truth, I've found it helpful for monitoring my own flow. I guess I've really yet to hear others describe how they use them, especially Veracity and holatuwol. I'm sure they would have a lot of insight as to how those permission words affect their work, if they care to comment. Please?
/ot
Continuing the veer, I seem to recall hearing about an exploit that was rooted in the ability of a Java class in one jar file being able to masquerade as a class in another (trusted) jar because some methods were not private to the trusted jar. That might have been back circa Java 1.2 or 1.3.
For a scripting language, where the source is readily available for manipulation, the concept of "private" seems to serve two functions. One would be to indicate to the user that things might change. The other would be to assist in namespace definition and disambiguation.
For a scripting language, where the source is readily available for manipulation, the concept of "private" seems to serve two functions. One would be to indicate to the user that things might change. The other would be to assist in namespace definition and disambiguation.
roippi
Developer
That is indeed the intent - to prevent breaking encapsulation. Of course, the determined programmer can basically always get around this, via reflection or simply modifying the source, given access. All you've really done is make it a pain in his ass to circumnavigate your directive on who/what can use the attribute.
Ultimately you really have no idea how your code is going to be used - even by yourself! So many times I've ended up increasing the visibility (or I wrote getters/setters - different topic) of a field that I wrote because I expanded the scope of what I originally intended it for. Who knows what use some other brain could come up with
Indeed those are the goals. For the former, I prefer naming conventions to convey my recommendation that you not touch the field/attribute/method/function/class. For the latter, I prefer mechanisms like name mangling over compiler restrictions that tell me I simply can't do it.
These are entirely my opinions and not gospel, of course. They come from long hours in programming in various languages and the eventual desire for some of those languages to get out of my way so I can get back to being productive. YMMV
zarqon
Well-known member
Who knows what use some other brain could come up with
Speaking of which, the latest update is specifically for brains. Mainly to account for their absence from item_drops_array().
We have a new function braindrop(monster), which returns the brain dropped by a given monster. Bosses drop boss brains, certain phyla never drop brains, etc. Always returns $item[none] outside of ZS.
This function is not likely to be particularly useful to most scripts, however its inclusion in ZLib was necessary for has_goal(monster) to account for goal brains -- which it now does. Likewise, BatBrain can use the function when calculating monster value, since brains are, in fact, worth something.
Ambar
New member
I hesitate to be the first to post this, but since today's update to zlib (r19) I've started seeing this error:
Expression syntax errors for 'modifier_eval()':
Can't understand dmg (zlib.ash, line 185)
My mafia-fu isn't sufficient to see the problem, and I'm not sure how to roll my local copy back to r18...
Expression syntax errors for 'modifier_eval()':
Can't understand dmg (zlib.ash, line 185)
My mafia-fu isn't sufficient to see the problem, and I'm not sure how to roll my local copy back to r18...
Ambar
New member
That was in fact the case; thanks all.
I"m seeing a similar error with zlib (also line 185).
Code:
Expression syntax errors for 'modifier_eval()':
Can't understand bestknife*1.25 (zlib.ash, line 185)Would someone be able to explain this error to me?
I"m running the latest Kolmafia (using Warp to update to daily builds).
Thank you in advance,
m00gam00g.