Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

ahkstdlib Collection - Should I stop the Basic support?


  • Please log in to reply
76 replies to this topic

Poll: Should I drop the support of AutoHotkey Basic in next updates? (40 member(s) have cast votes)

Should I drop the support of AutoHotkey Basic in next updates?

  1. Yes, concentrate on AHK_L only. (26 votes [63.41%])

    Percentage of vote: 63.41%

  2. No, AHK Basic will be a standard for long time. (15 votes [36.59%])

    Percentage of vote: 36.59%

Vote Guests cannot vote
jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009

I was asking if I should continue to collect the already available libraries.

Wouldn't be a bad idea - plus then they could start to be updated to be Basic & _L compatable, if that's desirable.

Tuncay <mobile>
  • Guests
  • Last active:
  • Joined: --
After reading your good opinions on both sides and the current votes, I think I continue for now with mixed style. And when v2 is matured, then i switch completly to it. And then someone other can take the job over for Basic or _L.

rancoll
  • Members
  • 1 posts
  • Last active: Apr 07 2012 07:57 AM
  • Joined: 27 Jun 2011
Basic is dead. Just keep L growing, only!!! UDF must have uniform standards likes the au3. Why Au3 is so popular? That's it.

Tuncay <mobile>
  • Guests
  • Last active:
  • Joined: --
But there are Basic users still and I do just collect for them. Its not like writinf new one. I just dont want loose them. They can be found in the forum too.

shajul
  • Members
  • 571 posts
  • Last active: Aug 01 2015 03:45 PM
  • Joined: 15 Sep 2006

But there are Basic users still and I do just collect for them. Its not like writinf new one. I just dont want loose them. They can be found in the forum too.


One way to look at it is, no (or very few, to be generous) libraries are being written for basic. Why not just keep the old collection as it is (not much has changed to that set), and start of with a new collection for AHK_L/v2?
If i've seen further it is by standing on the shoulders of giants

my site | ~shajul | WYSIWYG BBCode Editor

Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006
What would you say, if we form a group with members who decide and work on a brand new and fresh collection. In example, it could be Class only based. We write a document first, which describes some requirements, for being called a standard library. In example no global variable should be used. Documentation in a standard format is required too. And we help others to port their code. If a member have not much time, the whole project goes on with the other members.

At the beginning, there will be little libraries included. But if we work on it, then it grows and grows; ... with quality. Then it can be called "Standard". Our community needs some organization and collaboration. But it should not be too much work. Or it never gets true. And I am still for an downloadable archive, instead of online archive.

What do you think? What would you do and who is interested to work together?

No signature.


n-l-i-d
  • Guests
  • Last active:
  • Joined: --
No, please try to support both (or more, including the other existing versions, like AutoHotkeyH, AutoHotkeyCE and IronAHK)...

A complete and balanced standard lib for Basic has been long overdue, so why skip the chance, and start with Basic and adapt/use another version of that script for all the other versions of AutoHotkey.

Only if things are impossible in Basic, ok.

But, for heavens sake, don't start this kind of project with a class-library.

:?:

Tuncay <not logged in&
  • Guests
  • Last active:
  • Joined: --
Thats why I started this thread. I cant decide... It is a see-saw.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
Enforcing classes doesn't make sense, simply because there are some functions that don't require to be put into classes. They should be used though where it is reasonable.

nimda
  • Members
  • 4368 posts
  • Last active: Aug 09 2015 02:36 AM
  • Joined: 26 Dec 2010
I'd like to see something like this: (slight rewrite of AHK to add this in)
Lib\
   cSomething.ahk ; the c is optional? or required? We can call these such as Something.Init()
      Class something
      {
         Init(){
         }
         Lol(){
         }
      }

   MyLib.ahk ; Lib file, no prefix. Call these like MyLib_Init()
      MyLib_Init(){
      }
      MyLib_Lol{
      }

   SingleFunction.ahk
      SingleFunction(){
      }


Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006
Ok, that is a bad idea to enforcing Classes. I forgot the simplicity principle wins, especially in AutoHotkey. :oops:

No, please try to support both (or more, including the other existing versions, like AutoHotkeyH, AutoHotkeyCE and IronAHK)....

These other versions aren`t much related to standard Windows scripts. Mixing them together into a single collection brings more problems. What should a user do with a script for AutoHotkeyCE? It cannot be tested like now and the target is a completely another machine. And is not AutoHotkeyH included in current AutoHotkey? And for IronAHK this is too early, like v2.

@nimda
Why would you like to have an optional c in filename? ... and
Isn`t MyLib in this case the prefix?

No signature.


nimda
  • Members
  • 4368 posts
  • Last active: Aug 09 2015 02:36 AM
  • Joined: 26 Dec 2010
First off, I would maybe like to see the c so it doesn't conflict with other libraries (cIni, cFTP...)
Also, this could help interpreter to distinguish between looking for funtions or classes, although the interpreter could figure that out itself. I'd actually like responses to the idea; I'm open-minded.

Second, I meant no prefix as in not "LMyLib" or "fSomething" etc. As opposed to the 'c' which again is open for discussion. It might be okay to drop the c, but there will be classes with the same name as existing libs.

Tuncay <mobile>
  • Guests
  • Last active:
  • Joined: --
Classes should have an dedicated directory. That would us allow to install old versions with classes together (same name clash problem) and is less confusing than a c-prefix, imo.

shajul
  • Members
  • 571 posts
  • Last active: Aug 01 2015 03:45 PM
  • Joined: 15 Sep 2006
@Tuncay & nimda:
Classes can be wrapped as library as shown in my FTP lib -> <!-- m -->http://www.autohotke...pic.php?t=73544<!-- m -->

@Tuncay:
.. and the name of the new library will be FTPv2
If i've seen further it is by standing on the shoulders of giants

my site | ~shajul | WYSIWYG BBCode Editor

sumon
  • Moderators
  • 1317 posts
  • Last active: Dec 05 2016 10:14 PM
  • Joined: 18 May 2010
I actually think adding the cPrefix() to classes, especially those intended for library usage, makes alot of sense! Much like the traditional multifunction libraries use underscores to denote their difference functions, such as ini_getValue() and ini_replaceSection(). Ini might be a poor example since there are a bit too many ini libraries, but on the other hand it's nice to be able to write something that makes sense when writing a script. Sure, we can make functions that look like this:

#x::
Value := YourMum("Hello")
Birthday(Value)
return

YourMum(lol)
{
return StrLen(lol)
}

Birthday(yay)
{
MsgBox Oh my god! It's my %yay%th birthday!
return
}

... but that would make it so annoying to code. It's common sense that stuff should be "logically named".

And I personally find "cIni" or "cFTP" very easy to understand.

So, in short:

- Include classes in StdLib collection!
- Authors should name class libraries c%Class%, especially if the name is already occupied.
- It might not prove to be such a hassle to keep basic support after all, just look over what we have now slightly (if that was ever the intention) and in the future, tag all libraries as AHK_L compatible only, unless otherwise stated by author, or reported by users.

By the way, I am thinking of a rating/collection categorisation effort of libraries and also scripts that could then also be displayed online, particularly as a feature on the new page. The current wiki is way out-of-date, and when someone looks at the script showcase, although the scripts are indeed useful, god-knows how old they are. Would people be interested in this?

We need to modernize AHK.com badly, in my opinon. It's a bit frustrating to live with the feeling that you're browsing a cadaver.