requires blizz_mapinit

03-10-2009, 02:39 PM

I am thinking of making libraries run before map init stuff (creation of units, global setup etc) scopes will still run after them. However, it is all possible your library needs to be executed after this so much syntax is such as the title, "blizz_mapinit" would be a dummy library that represents those init stuff. Any other ideas?

How about adding a way to make libraries run before blizzard.j BlizzardInit? Then I would need a requires blizz_init stuff to specifically say it should run after blizzard.j how many libraries out there mess with blizzard.j stuff ?

03-10-2009, 03:18 PM

Anitarf

I don't know how many, but even if it just a few breaking their backwards compatibility is wrong. The library initializer running before the blizzard init should be the exception requireing additional keywords, not the other way around. Maybe something like a "preinitializer" keyword for library declaration? While you're at it, what about ingame initializers (for stuff like multiboards that can't be done at map init). It'd be nice if you could declare a preinitializer, an initializer and a postinitializer for each library.

03-10-2009, 03:29 PM	#3
xombie	I second Anitarf I can see those suggestions being put to good use.

03-10-2009, 03:46 PM

Vexorian

Quote:

The library initializer running before the blizzard init should be the exception requireing additional keywords, not the other way around

... but what keywords? requires wouldn't work any longer.

03-10-2009, 03:54 PM

xombie

Hmmm... I am going to deviate from Anitarf's suggestion and branch off onto a different (though same idea) suggestion. Rather than using a different word other than initializer, which as Vex said would disable the requires keyword, why not include it in the library's syntax, such as library_once does.

I'm going to start a list of ideas that you could use for naming. In all cases, I think that library as it is should be left alone, for backwards compatibility.

Pre-Blizz Initializer

library_onBlizz
library_onblizz
library_onInit
library_oninit
library_blizz
library_init
library_pre

Game Start Initializer

library_onGame
library_ongame
library_game
library_post

This way none of the other keywords are messed with, and backwards compatibility still works, just with added functionality. I just saw the post where you describe what it is needed for, and I wouldn't have any problem at all with you adding that functionality, though I would prefer if you used something like library_init for that. That is probably my most favorite in the list.

03-10-2009, 04:46 PM

Vexorian

Quote:

Hmmm... I am going to deviate from Anitarf's suggestion and branch off onto a different (though same idea) suggestion. Rather than using a different word other than initializer, which as Vex said would disable the requires keyword, why not include it in the library's syntax, such as library_once does.

hmnn, over my dead body :) too many new keywords for starting a library.

I prefer breaking backwards compatibility at least in case of the map's init, making libraries run before that garbage makes a lot of sense, for blizz' init I'll just ignore that addition, it is not that necessary.

03-10-2009, 05:04 PM

xombie

Quote:

Originally Posted by Vexorian

I prefer breaking backwards compatibility at least in case of the map's init, making libraries run before that garbage makes a lot of sense, for blizz' init I'll just ignore that addition, it is not that necessary.

I'm confused - so you're implementing libraries before?

I don't think its that many keywords... you're just adding the _init tag after a library for libraries that you wish to be declared before the blizzard initializer. There is really only one new keyword and its not so much a keyword as an extension of the library declaration.

JASS:

library_init LibraryName initializer someInitializer
private function someInitializer takes nothing returns nothing
    call DoNothing() // :P
endfunction
endlibrary

This doesn't seem very "strange" to me to use whatsoever... in my opinion this is one of the most simple approaches. I honestly cannot see a down-side to this.

Other than me having to kill you, why would this not be an applicable idea? You would prefer breaking backwards compatibility over a simple and barely noticeable syntax update?

I don't think that doing it your way would have too many repercussions either but it also eliminates the ability for the user to place a library in what was once known as "Custom Script", which is was the entire idea of libraries way-back-when.

03-10-2009, 05:12 PM	#8
akolyt0r	second xombie ... although it dont like plain _init .....i would like something like _preBlizz or _preBlizzInit seems to be much better than requires blizz_mapinit

03-10-2009, 05:35 PM

xombie

akolytor, don't you think that it might seem a little out of place to be declaring libraries like so:

JASS:

library_preBlizzInit LibraryName initializer init

private function init takes nothing returns nothing
endfunction

endlibrary

The _preBlizzInit is longer than the library keyword. I don't know, it just doesn't seem as native as a simple library_init. Perhaps you do not feel that _init describes its function well enough?

Hmm.. while we are on the topic, is SFilip still doing TESH? I noticed that library_once does not get bolded by the syntax highlighter.

03-10-2009, 05:53 PM

#10

akolyt0r

Quote:

Originally Posted by xombie

Perhaps you do not feel that _init describes its function well enough?

excactly ..

Quote:

Originally Posted by xombie

Hmm.. while we are on the topic, is SFilip still doing TESH? I noticed that library_once does not get bolded by the syntax highlighter.

readonly doesnt get bolded either ... :(

03-10-2009, 05:57 PM

#11

xombie

akolytor, perhaps we could use this thread to think of better ideas for naming, though do you really not think that _preBlizz and _preBlizzInit are a little too much? Also, keywords are typically all lower-case, and I don't think that _preblizzinit looks very nice - though _preblizz doesn't look too bad, its a bit long.

library
preblizz

Hmmm, I'm going to start a new list based on your ideas and mine.

Syntax Options

library_init
library_preblizz
library_front
library_fore

The last two were just pulled off of Thesaurus.com :P

03-10-2009, 06:00 PM

#12

akolyt0r

still _init suxx ...well ..Vex will pick the one which suits him best

OT:damn ...havent seen zocz edit ..sme time ago
latest TESH-build download with keyword, library_once, stub, delegate, readonly

Attached Files

TESH_0.7.0.2.7z (576.6 KB)

03-10-2009, 06:08 PM	#13
xombie	Ah, that is much better. Do you have any other ideas for syntax?

03-10-2009, 09:00 PM

#14

Anitarf

Whether library code comes before or after blizz init code is irrelevant because the blizz code won't be calling custom libraries anyway. The only thing that actually matters here is when init functions are run. That is why I suggested linking this functionality to the initializer keyword. I don't see how requires would no longer work in that case. If you have library X which uses either a regular initializer or a postinitializer (if implemented) and then you want to write a library that requires this library X, then it's obvious your library can't have a preinitializer function, at least not one that depends on library X being initialized. This should work without problems:

JASS:

library A preinitializer Init
    public trigger t
    private function Init takes nothing returns nothing
        set t=CreateTrigger()
    endfunction
endlibrary

library B postinitializer Init requires A
    private function Init takes nothing returns nothing
        call TriggerRegisterSomeEvent( A_t, EVENT_WHATEVER )
    endfunction
endlibrary

03-10-2009, 10:35 PM

#15

xombie

Quote:

Originally Posted by Anitarf

The only thing that actually matters here is when init functions are run. That is why I suggested linking this functionality to the initializer keyword

I'm not quite sure about that. Let me give you an example.

JASS:

library A initializer init

private function enumSomething takes nothing returns nothing
    // do something
endfunction

private function init takes nothing returns nothing
    local group enum = CreateGroup()
    call GroupEnumUnitsInRect(...)
    call ForGroup(enum, function enumSomething)
endfunction

endlibrary

In this case, you would have to move both enumSomething and init to a position before the blizzard initializers.