| 
 | 
 
| 
 
xemacs
 
 | 
 
| 
 xemacs 
 | 
hi you should add a feature to use classes classes should be build up in this way 
class foobar {
 ; var %all.vars.used.in.this.class
 ; in this example %var
 var %var
 alias myfunction {
  return $this->%var
 }
 alias setvar {
  set $this->%var $1-
 }
}
class barfoo extends foobar {
 alias increasevar {
  inc $this->var
 }
}
usage of a class create $foo new foobar $foo->setvar foobar echo -a $foo->%var would echo foobar then that feature would be a realy strong element in mirc scripting , ie you could create a object for each channel when u try to create a custom switchbar over all it would be REALY usefull sry for my crappy english   greetz   
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
| 
 
codemastr
 
 | 
 
| 
 codemastr 
 | 
I'd love to see OOP added to mIRC, however I don't think it will ever happen. Khaled seems reluctant to add even minor language enhancements. I have no idea how many times for() was suggested, yet it's still not in mIRC, and now switch() is being suggested a lot too, yet it hasn't been added, it wasn't until recently that Khaled even made it sound like he would consider adding switch(). So basically, I'd love to see it added, and I'd fully support having it added, I just wouldn't get my hopes up.   
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  May 2003 
Posts: 161  
Vogon poet 
 | 
 
 
Vogon poet 
Joined:  May 2003 
Posts: 161  | 
I don't think OOP really belongs in an IRC scripting language.  
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
| 
 
codemastr
 
 | 
 
| 
 codemastr 
 | 
Why not? Because it makes writing scripts 5000000x easier? Imagine this (Javaish): 
import mirc.floodkicker;
class NickFloodKicker extends FloodKicker implements OnNick {
   public NickFloodKicker(%channel) {
      ;Set this to monitor on %channel
      super.monitorChannel(%channel)
      ;Set a flood as 5 in 60 seconds
      super.setFloodLimit(5,60) 
   }
   public OnNickChange(%oldnick, %newnick) {
      ;On nick change, increase the flood count
      if (%oldnick ison $this->%channel) {
         ;Increase the number of actions for this user
         super.increaseAction(%oldnick)
         ;Change the name of the counter, so that it is now called %newnick so it can still be monitored
         super.renameFloodCounter(%oldnick,%newnick)
      }
   }
}
/new $NickFloodLimit(#test) And that would be all you'd have to write to make a nick flood kicker. The FloodLimit class, which would either be internal, or written by someone else for reusability, would handle everything else, the testing if it 5 in 60 seconds, resetting the counter, kicking the user, etc. All you have to do is tell it to monitor the channel, and to increase the number of recorded actions by that user. You are going to tell me that doing it like that is not useful? Imagine how many other dozens of taks would be simplified. Another example would be an MP3 player, all the basic stuff, playlists, play/pause/etc. would be in an MP3 class, then when you create an MP3 player, you just have to add to the prebuilt playlist and create a GUI. It would simplify virtually EVERY script task I can think of. Think of the current nick flood scripts, are you going to tell me you could, using mIRC's current scripting system, create a nick flood kicker as easily as I just did?      
Last edited by codemastr; 27/08/03 08:04 PM.
 
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
| 
 
xemacs
 
 | 
 
| 
 xemacs 
 | 
hm i think your way is a bit to object orientated and imo to complex for mirc scripting lang  
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Dec 2002 
Posts: 2,884  
Hoopy frood 
 | 
 
 
Hoopy frood 
Joined:  Dec 2002 
Posts: 2,884  | 
I'm pretty sure in the last switch thread Khaled said a switch statement was on his to-do list, so I don't think it's a case of not wanting to develop the language. More likely it's down to prioritising the planned additions and deciding that 'code style' changes like switch and for statements aren't necessities. The fact that it's been a year since the last release suggests that some big changes have been made - hell, maybe the next mIRC release has already got OOP by the bucketload. Maybe.
  If objects are added to mIRC scripting I just hope they don't use the PHP style demonstrated in the original suggestion. IMO the -> style is ugly.   
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
| 
 
codemastr
 
 | 
 
| 
 codemastr 
 | 
The -> style is certainly NOT a PHP invention, it is a C feature, it means "access a member and dereference the pointer", I just used -> as an example, . could just as easily be used. However, I thought . was a bad idea since that is already how mIRC uses properties. Is $someclass(blah).%count saying access the member of someclass called blah with member %count or is it saying $prop = %count? -> solves this ambiguity.
  And you are right, Khaled did say switch() is on his to-do list, however he also implied that it is very low on his list.  
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Jan 2003 
Posts: 2,973  
Hoopy frood 
 | 
 
 
Hoopy frood 
Joined:  Jan 2003 
Posts: 2,973  | 
I kinda wish Khaled had a base class (mircEvents, or some facsimile) that we could program and inherit the class and "Script" in c.  Use a call like /loaddll <dllname> <class> that would make use of the class, and give the ability to overload functions like onChannelText or onChannelAction 
class mircEventsClass: myPersonalClass {
  private override void onChannelText(char *chan, char *nick, char *msg) {
    //blah
  }
  private override void onQueryText(char *nick, char *msg) {
    //more blah
  }
}
   
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
| 
 
xemacs
 
 | 
 
| 
 xemacs 
 | 
yea that would be a realy nice feature for theming engines or faster bots ( i know only a few ms faster    )   
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Jan 2003 
Posts: 119  
Vogon poet 
 | 
 
 
Vogon poet 
Joined:  Jan 2003 
Posts: 119  | 
This would complete reinvent the wheel of mIRC scripting. Is it really that required? I wouldn't think so. Just write your stuff in DLL files and call to it that way? 
  After re-reading the code, I do like the idea of having such an event that could change a variable or whatever to monitor a diffferent one in real time w/o  re-initializing the entire event over again. That could be useful, otherwise I don't see the point to any of the other stuff. 
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Feb 2003 
Posts: 308  
Fjord artisan 
 | 
 
 
Fjord artisan 
Joined:  Feb 2003 
Posts: 308  | 
If you think about it; you'll notice there are quite a few advantages of OOP. Sure it has its shortcomings, but far far often they are more than compensated for.
  What I'd like to see first is a 'psuedo class' which merely defines its own varibles and aliases as local - no nasty constructors, destructors etc. Sure a script file does it at the moment with alias -l, and also a little with groups. Perhaps it could do a little more :P
  Then, when no one is looking, perhaps we can slip in method overriding...
    
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
| 
 
astigmatik
 
 | 
 
| 
 astigmatik 
 | 
I know that this is an old topic BUT I'd just donate my two cents here and I hope Khaled will not make it Java-style if ever he adds classes. It just sucks; all the extends, implements. 
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Apr 2004 
Posts: 755  
Hoopy frood 
 | 
 
 
Hoopy frood 
Joined:  Apr 2004 
Posts: 755  | 
whats not to like about extend ?  With php i have a general database class and 90% of my other classes extend that database class so i dont have to initiate a new  database class inside that class whenever i need to do something with the database. I hardly ever use Interfaces and therefor "implements" since i just can't be bothered though i can see a use for it with publicly available code. Interfaces would be alot of overkill for mIRCscripts. "extend" would definitely rock imo since you'll have code inheritance.  Eventhough i love Javascript OOP for its obscurity and fun to play with atleast Java atleasts seems to implement a general class driven syntax.  Some cool idea's in this thread though thanks for digging it back  up!    
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Dec 2002 
Posts: 580  
Fjord artisan 
 | 
 
 
Fjord artisan 
Joined:  Dec 2002 
Posts: 580  | 
I like the idea in part, but due to mIRC's syntax I wouldn't implement inheritance, polymorphism, instances, exceptions, or assertions; only static classes, constants, and encapsulation. Trying to change a constant should be quitely ignored. I think this is a more mIRC-ish way of doing classes... 
; access modifier ( -c = constant, -P = public, -p = private )
class TextFormatter {
  ; Private class variables
  var -cp %Logo ~Logo~
  ; Public class methods
  alias -P Echo { echo -a $1 }
  alias -P Logo { return %Logo }
}
alias useClass {
  TextFormatter.Echo $TextFormatter.Logo
}
 
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Dec 2002 
Posts: 2,884  
Hoopy frood 
 | 
 
 
Hoopy frood 
Joined:  Dec 2002 
Posts: 2,884  | 
The idea of private and public seems unnecessary for mIRC scripting. For a language that has always tried to be easy to pick up the use of private/public seems counter-productive. Same too for constants - there'll clearly be no performance benefit to them so there's no need to limit the scripters ability. For both public/private variables and constants If the scripter knows what they're doing then there's no reason not to allow them access to change  any variable, and if they don't know what they're doing they either shouldn't be doing it or should be ready to see things break in the name of learning. If classes are just going to be static then it seems you might aswell use the existing ability to use periods in aliases and stick to a  class.method naming convention. Trying to change a constant should be quitely ignored. If something fails it should raise an error. Trying to sweep errors under the carpet just encourages bugs.  
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Jan 2007 
Posts: 259  
Fjord artisan 
 | 
 
 
Fjord artisan 
Joined:  Jan 2007 
Posts: 259  | 
You're demonstrating something more like a namespace. There is no point in making classes if they're not instanced. 
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Jan 2003 
Posts: 1,057  
Hoopy frood 
 | 
 
 
Hoopy frood 
Joined:  Jan 2003 
Posts: 1,057  | 
also, I know of more then 1 person who use . in their alias names... so it would break quite a few scripts 
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Jan 2007 
Posts: 259  
Fjord artisan 
 | 
 
 
Fjord artisan 
Joined:  Jan 2007 
Posts: 259  | 
I'd suggest using  ->, since most programming languages use it =) 
class classname {
 init {
  private var %x = $1
 }
 public alias test {
  return $calc(%x - $1)
 }
}
alias useclass {
 var @x = $classname(1234), @y = $classname(4321)
 echo -a @x->test(4) - @y->test(1)
 set @f $classname(123)
.timer 1 5 ehco -a @!f->test $eval(|,1) unset @f
}
;Output:
[0] 1230 - 4320
[1] 123
(number enclosed in []s is a timestamp, from the start of /useclass.)
There are many different ways of doing it, but i'm certain this wouldn't be the best way to make then =)  
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Jan 2003 
Posts: 1,057  
Hoopy frood 
 | 
 
 
Hoopy frood 
Joined:  Jan 2003 
Posts: 1,057  | 
actually most programming languages I know use .
  only C uses -> for pointers and PHP (scripting language) uses -> 
 
 |  
 
 | 
 
 
 |  
 
| 
 | 
 
Joined:  Jan 2007 
Posts: 259  
Fjord artisan 
 | 
 
 
Fjord artisan 
Joined:  Jan 2007 
Posts: 259  | 
Ah, my bad. Been a while since I did C++, and I've been using PHP over the past few months       
 
 |  
 
 | 
 
 
 |  
 
 
   |  
 
 |