Forums Feature Suggestions /sockread -tN

This is pretty common and happen pretty often, you read something from a socket and you immediately tokenize it, usually with space:

I suggest having a new switch to directly fill $1- instead of using a %variable:

Yeah, thats a very good idea +1

+1 from me aswell.

Your suggestion really obfuscates the code.

I suggest...

Obfuscates, really?

You need a way to tell mIRC how to read, this is done with /sockread and won't change.
Why are you introducing a new identifier out of nowhere?
How is my code obfuscating anything?
Your version doesn't have anything better, it's just a different way to do it, but which is introducing a new identifier for no good reason

Assuming you mean $sockread would return a line from the buffer, people would use /tokenize N $sockread already, but it doesn't exist.

If you want to suggest $sockread, make a new thread about it, I think /sockread -t would be useful regardless of $sockread because it lets you use /sockread's behavior, you could use -f for example, $sockread itself wouldn't allow you to do that, so perhaps $sockread(f) to require that switch, but introducing a new identifier here seems unecessary to me.

Your suggestion makes it harder to read for those less familiar with the /sockread command and it's switches, IMO. They'll see /sockread but the -t32 will have them scratching their heads. I doubt you know what every switch for every command does. I know I don't. Good code should be easy to understand even if you aren't an expert at it. The command /sockread tells that it does a socket read, but -t32 tells you nothing and is something that has to be looked up.

Yes my way is just a different way of the same thing you suggested. Identifiers are added all the time, and it is for a good reason. The one you suggested, provide a simpler way of tokenizing the incoming socket string.

You're basically saying the name of a command or, of an identifier, is clearer than a switch because the name is much more meaningful, and that I agree, but switch usually have their letter based on the function done by that switch, both versions are readable...
If you argu that 'tokenize 32 $sockread' is better than '/sockread -t32 %name' because -t32 tells you nothing, well what about $sockread?
Considering mIRC never had anything similar, I can easily argu that $sockread is as confusing, as less known, than -t32, both would arguably be looked up.
Now, in the examples, you see $1- being used, there is no $1- inside the on sockread (or sockclose) event, so somewhere, someone tokenized.
Like I said $sockread doesn't say much about how the line was read, where /sockread -t wouldn't change the way a line was read.
This $sockread suggestion is entirely independent of this current suggestion and would require much more work to do a simple /tokenize on the result than -t would, and it could be used to read anything, it shouldn't be added just for this tokenization thing.
Yes your way is just a different way, but I just pointed out how it's not better.
If we had both right now, I'd use /sockread -t32

I like the idea of being able to tokenizing from the /sockread command, but I don't think the tokenization should alter the sockread command. That is to say, it should still fill a specified variable, and then tokenize what it filled said variable with:


Doing it as such would allow for current behavior to be maintained while adding the tokenization functionality

Exactly, it should only fills $1- but would still do it's job, I never wanted the current behavior of /sockread to be changed, sorry if that wasn't mentioned or unclear, seems a bit obvious to me though, I wouldn't ask to break /sockread just to quickly tokenize

edit: I just realized I originally asked it to replace the %variable, the syntax would change but it wouldn't break. Either way, I think I originally suggested to get rid of the %variable because if you are using $1-, you will usually not need that %variable, but as long as it tokenize, we'd be happy.


Another good point from Talon, creating a local variable before /sockread because it would create a global variable otherwise, it's the same idea as -t, it's something almost all scripters do, because we usually never need a global variable to be assigned the read of a socket's buffer.
I think it's ok to add it to this thread: a '-l' switch to /sockread to make that %variable a local one