Re: [Bro-Dev] Use of 'any' type
Actually, the 'as' operator is useful, since it appears that 'any' can currently only be cast into a string otherwise On Thu, Aug 16, 2018 at 2:58 PM, Jon Siwek wrote: > In the master branch, there are also type checking/casting 'is' and > 'as' operators [1] and type-based switch statement [2] that may be be > useful. > > - Jon > > [1] https://www.bro.org/sphinx-git/script-reference/operators.html > [2] https://www.bro.org/sphinx-git/script-reference/ > statements.html#keyword-switch > > On Thu, Aug 16, 2018 at 4:24 PM Jim Mellander wrote: > > > > Thanks, Johanna - I think type_name() may suffice for the purposes I am > envisioning. > > > > On Thu, Aug 16, 2018 at 1:57 PM, Johanna Amann wrote: > >> > >> Hi Jim, > >> > >> On 16 Aug 2018, at 13:40, Jim Mellander wrote: > >> > >>> It would be most convenient if the 'any' type could defer type checking > >>> until runtime at the script level. > >>> > >>> For instance, if both A & B are defined as type 'any', a compile time > error > >>> > >>> "illegal comparison (A < B)" > >>> > >>> occurs upon encountering a bro statement > >>> > >>> if (A < B) do_something(); > >>> > >>> even if the actual values stored in A & B at runtime are integral > types for > >>> which comparison makes sense. > >> > >> > >> I think this is a bit hard to do with how things are set up at the > moment internally - and it also does make type-checking at startup less > possible-helpful. > >> > >> However... > >> > >>> > >>> If the decision could be made at runtime (which could then potentially > >>> throw an error), a number of useful generic functions could be created > at > >>> the script level, rather than creating yet-another-bif. A useful > >>> yet-another-bif would be 'typeof' to allow varying code paths based on > the > >>> type of value actually stored in 'any'. > >> > >> > >> This already exists and I think you can actually use it to write code > like that; you just have to cast your any-type to the correct type first. > The function you want is type_name; it is e.g. used in base/utils/json.bro. > >> > >> Johanna > > > > > > ___ > > bro-dev mailing list > > bro-dev@bro.org > > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Use of 'any' type
In the master branch, there are also type checking/casting 'is' and 'as' operators [1] and type-based switch statement [2] that may be be useful. - Jon [1] https://www.bro.org/sphinx-git/script-reference/operators.html [2] https://www.bro.org/sphinx-git/script-reference/statements.html#keyword-switch On Thu, Aug 16, 2018 at 4:24 PM Jim Mellander wrote: > > Thanks, Johanna - I think type_name() may suffice for the purposes I am > envisioning. > > On Thu, Aug 16, 2018 at 1:57 PM, Johanna Amann wrote: >> >> Hi Jim, >> >> On 16 Aug 2018, at 13:40, Jim Mellander wrote: >> >>> It would be most convenient if the 'any' type could defer type checking >>> until runtime at the script level. >>> >>> For instance, if both A & B are defined as type 'any', a compile time error >>> >>> "illegal comparison (A < B)" >>> >>> occurs upon encountering a bro statement >>> >>> if (A < B) do_something(); >>> >>> even if the actual values stored in A & B at runtime are integral types for >>> which comparison makes sense. >> >> >> I think this is a bit hard to do with how things are set up at the moment >> internally - and it also does make type-checking at startup less >> possible-helpful. >> >> However... >> >>> >>> If the decision could be made at runtime (which could then potentially >>> throw an error), a number of useful generic functions could be created at >>> the script level, rather than creating yet-another-bif. A useful >>> yet-another-bif would be 'typeof' to allow varying code paths based on the >>> type of value actually stored in 'any'. >> >> >> This already exists and I think you can actually use it to write code like >> that; you just have to cast your any-type to the correct type first. The >> function you want is type_name; it is e.g. used in base/utils/json.bro. >> >> Johanna > > > ___ > bro-dev mailing list > bro-dev@bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Use of 'any' type
Thanks, Johanna - I think type_name() may suffice for the purposes I am envisioning. On Thu, Aug 16, 2018 at 1:57 PM, Johanna Amann wrote: > Hi Jim, > > On 16 Aug 2018, at 13:40, Jim Mellander wrote: > > It would be most convenient if the 'any' type could defer type checking >> until runtime at the script level. >> >> For instance, if both A & B are defined as type 'any', a compile time >> error >> >> "illegal comparison (A < B)" >> >> occurs upon encountering a bro statement >> >> if (A < B) do_something(); >> >> even if the actual values stored in A & B at runtime are integral types >> for >> which comparison makes sense. >> > > I think this is a bit hard to do with how things are set up at the moment > internally - and it also does make type-checking at startup less > possible-helpful. > > However... > > >> If the decision could be made at runtime (which could then potentially >> throw an error), a number of useful generic functions could be created at >> the script level, rather than creating yet-another-bif. A useful >> yet-another-bif would be 'typeof' to allow varying code paths based on the >> type of value actually stored in 'any'. >> > > This already exists and I think you can actually use it to write code like > that; you just have to cast your any-type to the correct type first. The > function you want is type_name; it is e.g. used in base/utils/json.bro. > > Johanna > ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Use of 'any' type
Hi Jim, On 16 Aug 2018, at 13:40, Jim Mellander wrote: > It would be most convenient if the 'any' type could defer type > checking > until runtime at the script level. > > For instance, if both A & B are defined as type 'any', a compile time > error > > "illegal comparison (A < B)" > > occurs upon encountering a bro statement > > if (A < B) do_something(); > > even if the actual values stored in A & B at runtime are integral > types for > which comparison makes sense. I think this is a bit hard to do with how things are set up at the moment internally - and it also does make type-checking at startup less possible-helpful. However... > > If the decision could be made at runtime (which could then potentially > throw an error), a number of useful generic functions could be created > at > the script level, rather than creating yet-another-bif. A useful > yet-another-bif would be 'typeof' to allow varying code paths based on > the > type of value actually stored in 'any'. This already exists and I think you can actually use it to write code like that; you just have to cast your any-type to the correct type first. The function you want is type_name; it is e.g. used in base/utils/json.bro. Johanna ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] Use of 'any' type
It would be most convenient if the 'any' type could defer type checking until runtime at the script level. For instance, if both A & B are defined as type 'any', a compile time error "illegal comparison (A < B)" occurs upon encountering a bro statement if (A < B) do_something(); even if the actual values stored in A & B at runtime are integral types for which comparison makes sense. If the decision could be made at runtime (which could then potentially throw an error), a number of useful generic functions could be created at the script level, rather than creating yet-another-bif. A useful yet-another-bif would be 'typeof' to allow varying code paths based on the type of value actually stored in 'any'. Any comments? Jim ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] Use of 'any' type
It would be most convenient if the 'any' type could defer type checking until runtime at the script level. For instance, if both A & B are defined as type 'any', a compile time error "illegal comparison (A < B)" occurs upon encountering a bro statement if (A < B) do_something(); even if the actual values stored in A & B at runtime are integral types for which comparison makes sense. If the decision could be made at runtime (which could then potentially throw an error), a number of useful generic functions could be created at the script level, rather than creating yet-another-bif. A useful yet-another-bif would be 'typeof' to allow varying code paths based on the type of value actually stored in 'any'. Any comments? Jim ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
