Novi tipovi varijabli - kako vam se čine i kako bi ih nazvali

Pozdrav,

zaigrao sam se malo i rekao bi da sam napravio nešto jako zanimljivo… i mnogo se dvoumim oko imena … i tu ću cijeniti sugestije.

Uglavnom, napravio sam nove tipove varijabli i za sada se tipovi varijabli zovu:

uservar x;
sticky y;
mirror z;
tabvar q;

uservar x - to je varijabla koja čuva stanja usera. Tako developer jednom kada definira tu varijablu, zna da će ga čekati ono što je definirao svaki puta kada je taj user logiran. Ne mora misliti o serveru, bazi podataka …ničemu.

sticky y - ovo je slično ko uservar varijabla, samo ostaje živjeti i nakon što se user odlogira. Ovdje neka komponenta može držati vlastita unutarnja stanja.

mirror z - ovo je varijabla koja je nalik sessionu, što se tiče dužine života. Samo je karakterizira to da je ista u svim paralelnim tabovima koje posjetioc otvori. Što olakšava izradu multitab aplikacija …jer što god korisnik napravi u jednom tabu, živo je i u drugom tabu. Uz ovu varijablu dolazi i event:

event.on("parallelMirroring_z", function(oldValue, newValue){
	
	console.log('parallelMirroring detect changed value from $oldValue to $newValue');

});

U pitanje imenovanja ubacujem i ime eventa: (on)"parallelMirroring" ??

tabvar q - to je pak skroz slično varijabli mirror, samo sa jednom razlikom što se ova varijabla ne preslikava na svaki otvoreni tab, nego svaki tab ima svoju vrijednost ove varijable. Ovo je zapravo poprilično poput session varijable, jer se tako ponaša po dužini života. No ima jednu iznimku, kako sessioni u browseru žive posebno na svakom individualnom otvorenom tabu nezavisno od drugih tabova…tako i tabvar je isto nezavisan između tabova. Ali ako se tab podupla klikom srednjeg klika miša na reload button, onda se zapravo dobiva kopija otvorenog taba i nativni session na tom novom tabu je isti kao i na originalu te kopije.
Isto tako i tabvar je isti na kopiji taba kao na originalu …ali je za razliku od sessiona sinkroniziran između ta dva taba u real time …na isti način kao što je mirror varijabla sinkronizirana između svih otvorenih tabova.

Heto, cijenit ću prijedloge imena…i generalno bilo kakvo mišljenje.
Inače, radi se o novom (client-side) programskom jeziku kojeg ja pravim. :joy: …ma bit će bonbon. Ma već je.

Evo malo i sintakse:

"@use sticky coutner {default:0}";
"@use uservar name, age";
{
	//async code...

	if(!age) age = prompt("Hej $name, what age are you?");  //jednom definirane godine svaki puta će biti dostupne
	//do something with age...

	counter++; //brojač, interno stanje komponente. Nikada se ne resetira osim ako ga svjesno resetiramo.


	"@set age,counter";  //stanja async varijabla je potrebno arhivirati set metodom nakon što želimo trajno sačuvati izmjene
}

"@use mirror text";
"@use tabvar options";
{
	if(text) $("#myTextarea").value = text;

	event.on("parallelMirroring_text", function(oldValue, newValue){

		$("#myTextarea").value = text;  // text je automatski ono što je newValue. To bi se desilo i da nismo koristili event. 
										// Event je tu samo da nas upozori da se neka varijabla promjenila u parallelnom tabu tako da možemo reagirati
										// u ovom slučaju ažuriramo vrijednost u textarea.
										// na ovaj način možemo kreirati aplikaciju gdje ćemo korisniku dopustiti da radi u više tabova, a nama se stanja neće poremetiti čak niti nakon
										// relaodanja nekih od tih tabova.
	});

	// showOptions() - neka je to metoda koja pokazuje opcije texteditora u zavisnosti od stanja options varijable
	showOptions(options); //korištenjem options tipa varijable "tabvar options" i "mirror text" omogućili smo da korisnik u svakom 
						  //paralelnom tabu može raditi na istom tekstu, ali da su mu u svakom tabu prikazane one opcije kako ih je sebi prilagodio na tom tabu

	//stanja mirror|tabvar nije potrebno spremati @set metodom ...jer su uvijek onakve kakve smo zadnji puta ostavili.

}

Kako sam shavatio to je sve nastalo da bi ti mogao raditi “multi tab” aplikaciju?
Zbog cega si odlucio baratati tabovima preglednika a ne raditi SPA sa nekim tab widgetom?

Nepotrebno sam se razvezao pa obrisao. xd.
Uglavnom, nije poanta u multi tab aplikaciji … što možeš vidjeti po tipu varijable “uservar”.

Novi tipovi varijabli - kako vam se čine i kako bi ih nazvali

Beskorisno i bespotrebno. Ne zato šta ih možda ne bi koristio, već zbog nepotrebnog kompliciranja i jako čudne sintakse s kojom izmišljaš toplu vodu.

Objasni mi ovo

"@use sticky coutner {default:0}";
"@use uservar name, age";
{
...
}

Da li je sticky dostupan i u ovom bloku? Ako nije, zašto nije? Ako je, zašto je?

"@use mirror text";
"@use tabvar options";
{
	sticky ???
}

Sama izvedba bi imala smisla kao package kojeg onda koristiš ovako:

import { useSticky, useTabvar } from 'čušpajz';

const [ sticky, setSticky ] = useSticky({
	counter: 0
});

console.log( sticky.counter );

setSticky({
	counter: 5
});

I onda ovaj tvoj lib mogu koristiti svi bez dodatnih loadera koji trebaju parsirati taj tvoj file.

Uglavnom, ne ulazim u samu potrebu i primjenu ovakvih stvari, ali implementacija ti je čudna. Koji su benefiti korištenja alternativne sintakse u odnosu na plain JS? Ako može odgovor bez nespojivih analogija i drobljenja gluposti. Ako ipak ne, onda shvati to kao retoričko pitanje.

1 Like

Od sintakse se očekuje par uvjeta:

  • da je jednoznačna
  • da je lako razumljiva čovjeku i računalu (compailerima)
  • da je jednostavna za tipkati čovjeku

Ova moja sintaksa ne narušuje ništa od tih pravila i zapravo nije uopće čudna, nego uobičajena u nekim nižim programskim jezicima. Tamo imaš logiku da se u zaglavlju skripte nabroje sve varijable onda otvaraš mainloop { … } u koji ide code koji radi sa tim varijablama. To je iz razloga jer se nekada više štedilo na registrima i zauzeću memorije koje će program koristiti …pa se unaprijed moralo znati koje sve varijable su u igri i koliko će bitova iste zauzeti.

Ja iz određenih razloga da bi ispunio zamišljenu funkcionalnost ovih tipova varijabli, isto moram unaprijed znati koje varijable će se koristiti u bloku sa vitičastim zagradama { … }, tako da sam pribjegao istom pristupu.

Je, dostupan je. Logika je dosta jednostavna…prvo pobrojiš sve varijable koje će se koristiti u tom bloku, zatim otvaraš blok. Sticky counter tako po ničemu tu nije drugačiji od uservar name i uservar age. Pri tome scope varijable živi točno ondje gdje je ona definirana…ali je spremna za korištenje tek u tom bloku nakon.

Ono što se meni jedino ne sviđa, ja bi da se piše još čišći code:

sticky counter;
uservar name, age;
{

}

No to sam zasada preskočio.Čisto iz razloga jer mi neki kompajleri to trenutno ne mogu progutati jer to više nija validna javascript sintaksa. Dok gornju sintaksu javascript vidi kao validnu, samo njima ima drugo značenje. Ti compaileri ne znaju što će naknadno ti stringovi proći…nego ih vide kao najobičnije stringove…
Zato je "@use uservar name, age"; umjesto samo uservar name, age; Ali u jednom momentu ću to lako moći transformirati u još više clean verziju, za sada mi je ok.

Ovo nikako nije rješavanje problema na razini compilera i sintakse…nego nešto sasvim drugo.
I ako poredim taj tvoj prijedlog code-a, spram ovog:

sticky counter = 5;

…jasno mi je bez dvoumljenja da želim pisati ovo drugo.
Programski jezici evoluiraju na način da uvijek sa manje sintakse možemo opisati više pravila …a ne obratno. Ovo tvoje onda nikako nije evolucija sintakse…a niti je uopće rješavanje problema na toj razini sintakse. Nemoj brkati metode sa pravilima ugrađenima na razini sintakse.

Kada bi mi to bio interes, išao bi drugim putem. Nemam nikakvih interesa da moj lib netko koristi, nego da unaprijedi i ubrza mene.
No moj lib će moći drugi koristiti, ali to se možda više neće niti zvati javascriptom. Jer radim nešto poprilično novo… i taj lib će se moći koristiti u posebnom containeru koji će biti namjenjen za to. Isto kao što je browser namjenjen da unutra vrtiš javascript, tako će se moj lib vrtiti unutar sistema koje sam nazvao “Doors”.

Otprilike kao da izađeš iz ovog svijeta koji je ograničen nekakvim pravilima…i uđeš u svijet snova gdje sam možeš kreirati svoja pravila. Postaješ tako neograničen i mogućnosti su beskrajne.
Recimo primjer, dok javascript nije uveo ECMAScript 6, svi koji su tipkali plain javascript nisu imali mogućnost da koriste bilo što od toga. A ja sam si neke od tih stvari sam omogućio prije nego je stigao ECMAScript 6. Kad je stigao ECMAScript 6, dobio sam samo potvrdu da sam ispravno razmišljao i išao pravim putem. Shvatio sam prednost koju sam imao i nastavio još jače tim putem.
Pisao sam o tome: Zašto pre-kompajlirati code
Ja to radim već dosta dugo i mogu reći da imam većinom benefite. Postoje naravno i minusi, ali Bože moj…sve ima svoju cijenu.

Evo malo više o ovome.
Jasno ti je da za funkcionalnost sticky tipa varijable (i uservar tipa) …da je tu uključen u priču server. Tako da onog momenta kada developer deklarira da će koristiti sticky ili uservar, počinje procedura povlačenja te varijable sa servera…tako da vitičasti blok se izvršava asinkrono nakon što je varijabla spremna/učitana. Dok je scope te varijable točno onaj unutar kojega varijabla jeste deklarirana.

A i tu se dalo fino poigrati… tako sustav samostalno uči koji page (url) vuče koje sticky/uservar varijable…i onda ih dostavlja već na razini loadanja stranice, tako da se taj asinkroni delay uspješno izbjegava.

Naravno, ne radi se sa svim varijablama inicijalno nakon loadanja stranice. Isto tako, ovisno o ponašanju korisnika što klikće, neće svaki puta biti potrebne sve varijable na client strani…pa bi bilo neoptimizirano ih slati sve na client stranu.
Zbog toga je napravljeno da sustav uči o prosječnom vremenu kada se neka varijabla poziva sa client stranice ili nakon kojeg eventa se poziva…pa pokušava pogoditi optimalno vrijeme da isporuči varijable na client stranu prije nego client strana zaista varijablu zatreba. I developer o tome ničemu ne mora misliti…on samo koristi “@use sticky varname”; … a sustav se dalje samostalno optimizira i uči kako bi posao obavio što efikasnije i kako bi client-side sučelje radilo brzo i bez zastajkivanja. (a da se pri tome ne šalje previše suvišnih podataka na clienta.) Eto, zato su vitičaste…one su garancija da će tu varijabla biti spremna. Taj blok se u većini vremena izvršava direktno bez ikakvog delaya…no postoji mogućnost da u tom momentu nastane delay zbog asinkronog poziva varijabli sa servera…te ga se mora tretirati kao asinkroni blok.

Sintaksa je skup pravila programskog jezika s kojima oblikujemo naš kod. Ovo šta si ti naveo nije sintaksa i nisu uvjeti sintakse. Sintaksa je strogo definiran način na koji pišeš kod da bi te kompajler mogao “razumjeti”. Npr. PHP zahtjeva ; na kraju svake linije i to je “uvjet sintakse”.

Ovo vjerojatno govori netko tko je probao programirati u C-u i to na mikrokontrolerima.

Kažem ti da ti je sintaksa čudna. Zašto onda ne bi imao na početku fajla definirane sve te varijable i onda ih koristio niže? Ovako moram otvarati blokove koji ustvari ne služe ničemu, ili služe asinkrono učitavanje. Heh, a kako je to onda tvoje bolje od async i await?

Ovo sam zaboravio komentirati u prethodnom postu.

"@use sticky coutner {default:0}";

Kako bi prosljedio malo veći JSON? Npr.

{
nesto: {
   ajme: 'je',
   meni: {
      nije: 'mi',
      dobro: true
   },
   nesto2: 'je',
   nesto3: false,
   data: [
      {
         ajme: 'ajme'
      },
      {
         ajme: 'ajme'
      }
   ]
}

Da li mogu proslijediti varijablu u

"@use sticky coutner varName";

Kako bi napisao gore navedeni kod kao sticky value? Ili to podrzava samo var: value?
Šta ako imamo 20 vrijednosti koje želimo spremiti?

Teško da će te ubrzati ako si ti jedini koji radiš na njemu, i kad konstantno moraš voditi borbu sa svojom implementacijom da bi “izmišljao” stvari koje rade out of the box u plain JS-u.

Nadam se da ću ga imati prilike isprobati.

Ova rečenica je kontradiktorna sama sebi. “Otprilike kao da izađeš iz ovog svijeta koji je ograničen nekakvim pravilima…i uđeš u svijet snova gdje sam možeš kreirati svoja pravila.” Od pravila do pravila, a šta ako ne želim definirati svoja pravila, da li još uvijek postoje pravila? Ako postoje, znači da me ograničavaju?!

Uglavnom, radi što želiš s svojim vremenom koje ti je dano, ali mislim da možeš bolje od ovog. Na kraju ćeš imati hrpu koda koju nitko osim tebe, a možda ni tebe, neće znati/moći koristiti.

A neg što je? Kao što si i rekao … sintaksa je skup pravila. Ta pravila ne oblikuje PHP, nego tvorac sintakse. U ovom slučaju ja sam oblikovao sintaksu i ne kužim po čemu misliš da to nije sintaksa?

Uzmimo za primjer SASS koji je isto nastao po istoj ideji da bude kompajliran u css … i sad ti dođi tvorcu SASSA i reci mu da to njegovo nije sintaksa, nego je css sintaksa. ??

A gore nabrojeni uvjeti su da sintaksa bude em pravilna (mora biti jednoznačna) … em da bude praktična za tipkanje ali da bude praktična i za kompajliranje. Jer što nebi HR jezik bio sintaksa za programiranje? Pa problem je u tome što iako bi se sa HR jezikom moglo opisati sve, ali kolika nauka je potrebna da se računalno razumiju te instrukcije i prevedu na set instrukcija razumljiv računalu?
Zato su bitni uvjeti koje sam nabrojao. Jednoznačnost i praktičnost (praktičnost i u tipkanju i u računalnoj obradi, kompajliranju) … a naravno, može se osmisliti uvijek kvalitetnija i manje kvalitetna sintaksa. Tu te vraćam da obrazložiš po kojim to kriterijima ono gore nije dobra sintaksa? Čudna kako kažeš?
Čudna ti je jer ju pokušavaš razumjet kroz javascript, no ona više nije javascript.

Ako ćemo o kritikama, mogu i sam započet:

  1. može jednostavnije, navodnici su malo suvišni. Objasnio sam zašto su tu.
  2. Nije skroz jednoznača, tj. blokira developera da napiše takav string ako to poželi. No ovaj problem u primjeni je ravan nuli jer nikad nemamo potrebi pisat string koji s lijeva ne pridružujemo nekoj varijabli. Tako da je to zanemariv problem.

Eto, to je konkretan osvrt… slobodno na taj način argumentiraj ako vidiš nedostatak toj sintaksi u primjeni. Uvažit ću rado konstruktivne primjedbe.

Ovdje na prvom mjestu treba imat na umu da je problem ako ova sintaksa ulazi u konflikt s nekom drugom sintaksom… jer nebi bilo čudno da neki od meni nepoznatih alata koristi nešto slično… pa bi se stvorio problem oko “jednoznačnosti”.

Ajde malo promisli i sam si odgovori na ova pitanja, jer sve je već napisano.

Kako ne služe ničemu ako daju garanciju da je tamo varijabla ready? Daju garanciju za slučaj da je došlo do asinkronog učitavanja.

A ako je sistem naučio pattern i reagirao i na vrijeme učitao varijablu…pa nije došlo do asinkronog delaya…onda ti blokovi sigurno neće smetati. Što ne znači da nisu služili… jer dali su garanciju i razdvojili su potencijalno asinkroni code od onoga koji će se sinkrono nastaviti izvršavati. Na developeru je kako će postupati sa codeom koji potencijalno može biti asinkrono izvršen. On se mora ponašati kao da se taj code izvršava asinkrono, a sustav se za njega brine da taj delay bude u većini slučajeva NULA.

Gubi se smisao ako su sve na početku definirane… pa definiraš varijablu unutar onog scopea/bloka gdje ti treba. Tamo je vidljiva, a izvan tog scopea nije. Kao i inače ponašanje lokalnih/globalnih varijabli…ni ovdje nije ništa drugačije.

Uz to… kad bi sve bile na početku definirane, onda sistem nebi znao kada je koja potrebna i nebi mogao raditi optimitmzaciju učitavanja… nego bi sve morao učitati odjednom. Što je generalno sran** po pitanju osnovne skalabilnosti.

Heh, a kako je to onda tvoje bolje od async i await?

A da napišeš kompletan code sa async i wait koji postiže istu funkcionalnost pa sam uvidiš koliko toga je strpano u dva keyworda sintakse?

Ne moraš, retorički je… samo razmisli što sam ti htio reći.
Ja nigdje ne govorim da je nativni Javascript loš, samo se može sažeti i uljepšat. Sve se ovo prevodi u javascript na kraju…

Meni je zapravo najveći problem, vrijedan diskusije… kako pratiti greške. Jer ona skripta na kojoj će browser vrisnuti gresku više nije copy paste skripta koju je kucao developer.

No otkako je raznih minimizera, ovaj problem postoji…i nekako se već rješava… ja za sada samo pazim da je output skripte nakon mog compilera isti po broju linija kao i source koji se kompajlira. I da se iste linije podudaraju … tako da je skroz prihvatljivo raditi/istjeravati errore. No ipak, to je fest težak zadatak koji čeka da bude pravilno riješen.

Ne baš tako kako si napisao, ali možeš ovako:
@use sticky coutner {default:SOME_VARIABLE}”;

Tvoje neće radit čisto iz razloga jer neće biti prepoznato od compilera kao očekivana sintaksa… pošto nemaš vitičaste koje su njegovi orijentiri.

…i to nije JSON, da te ne zavara. Unutra pišeš code sve isto kao i da nema navodnika. Možeš i javascript opracije ubaciti…tipa:

"@use sticky coutner {default:1+1}";

Vidi malo što će compalier napraviti iz toga… uzet će sve između vitičastih i kreirati sljedeći djelić codea:

var __about_uid = {default:1+1};
var sticky = __about_uid.default;

Malo sam pojednostavio i to je samo dio outputa da dočaram…no vidiš da sve što kucaš u tom objektu, postaje direktno plain javascript “with out effort”.

Jedino compalier na svojoj razini postavlja pravila što očekuje nakon taga @use. Tako da ako on tamo očekuje vitičastu zagradu, jednostavno neće progutati tvoju varijablu, ono što si pitao.
No da je compiler podešen da proguta i varijablu na kraju stringa… sve bi isto radilo. :slight_smile:
No to onda zalazi u održivost sintakse, jer i ona mora biti konceptirana da se može unaprijeđivati … ako je predviđeno da ide opcionalno vitičasta nakon naziva varijable, onda to postaje pravilo sintakse.

Griješiš… ali mnogi griješe po ovom pitanju, pa ti je oprošteno. :slight_smile:

Ako radiš na elementima koji te ubrzavaju, onda si svakim danom malo brži od prethodnog.
Jeste da će te to prvo strašno usporiti…jer si logično ostavio sve i radiš na nečemu što će ti se tek jednog dana vratiti… no matematika je jasna, vratit će se, samo sa odgodom.

I ta matematika, ako to pokušaš staviti na papir… pokazat će ti da ako konstantno radiš na (mikro) ubrzanju sebe … da brzina tvoje produktivosti svakodnevno raste i to prikazano na grafu kreira eksponencijalnu liniju rasta poduktivnosti.

S druge strane ako ne gubimo vrijeme na ta mikro ubrzanja sebe, mi smo u startu već jako brzi. Logično, jer smo usmjereni samo na cilj. Puno brži smo od onog što “gubi vrijeme” i radi na sebi… ali bez rada na ubrzanju, jašemo linearni graf produktivnosti… i naš tempo napretka je poprilično konstantan.

E sad, posto je taj linearni graf puno strmiji u početku od eksponencijalnog… mi svi nekako nesvjesno njemu težimo jer je on uvijek u datom momentu najkraći put da se obavi neki posao.
No najkraći put je samo u kratkoročnom pogledu, ako poredimo ta dva grafa na duže staze… eksponencijalni će uvijek prestići linerani. I ne samo prestići… ostavit će ga nemjerljivo daleko ispod sebe. Tipa eksponencijalni graf te može odvesti da postaneš Google ili Amazon…itd. … a ovaj linearni je jednostavno poprilično limitiran. Siguran budi da su i Google i Amazon na početku gubili drastično puno vremena da rade na sebi… a onda kada se ta uložena energija u sebe razgori, eksponemcijalnom grafu je nemoguće parirati. (Sa linernim)

E sad, posto u svakom trenutku našeg rada se mi opredjeljujemo ili na čim brže rješenje ili na rad na sebi koji će projecirati sporije ali kvalitetnije rješenje… treba to dvoje uskladiti. Najbolje je definirati si raspored i po tome uskladiti koliko vremena odlazi na prodornost (čim brže rješiti zadatak) a koliko na rad na sebi u što spada učenje ali i razvoj alata. (To nas je definiralo ko ljudsku vrstu… razvoj alata. To je jako bitno)

U nekim mojim počecima me taj pristup masu usporavao… ali bio sam svjestan matematike koju sam opisao poviše … pa sam bio ustrajan u toj logici. Trebalo mi je sigurno cca 10 godina… da moja eksponencijlna krivulja pestigne onu linearnu :smiley: i puno puta sam se putem zabrinuo i preispitivao tu logiku… ali trenutno smatram da mi se sve jako isplatilo.

Ne vidim ništa lošega u tome da imamo kontrolu nad pravilima koja nas ograničavaju.

Jer ako imamo tu kontrolu, to znači da možemo pomicati ograničenja, tj. da smo bez ograničenja. Istinski kreator.

P.S. istipkao sam upravo maratonski ovo sa mobitela, hehe … isprika na rascjepkanim postovima, tako mi je bilo lakše.